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Description 

METHOD AND SYSTEM FOR DNA 
RECOGNITION BIOMETRICS ON A FOB 

Cross Reference to Related Applications 

[0001] This invention is a continuation in part of U.S. Serial No. 

10/340,352, filed on January 10, 2003, and entitled "SYS- 
TEM AND METHOD FOR INCENTING PAYMENT USING RA- 
DIO FREQUENCY IDENTIFICATION IN CONTACT AND CON- 
TACTLESS TRANSACTIONS." The "352 application itself 
claims priority to U.S. Patent Application No. 10/192,488, 
entitled "SYSTEM AND METHOD FOR PAYMENT USING RA- 
DIO FREQUENCY IDENTIFICATION IN CONTACT AND CON- 
TACTLESS TRANSACTIONS," filed on July 9, 2002 (which 
itself claims priority to U.S. Provisional No. 60/304,216, 
filed on July 10, 2001); U.S. Patent Application No. 
10/318,432, entitled "SYSTEM AND METHOD FOR SELECT- 
ING LOAD OPTIONS FOR USE IN RADIO FREQUENCY IDEN- 
TIFICATION IN CONTACT AND CONTACTLESS TRANSAC- 
TIONS," filed December 13, 2002; U.S. Patent Application 



No. 10/318,480, entitled "SYSTEM AND METHOD FOR 
PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN 
CONTACT AND CONTACTLESS TRANSACTIONS," filed De- 
cember 13, 2002; and, U.S. Provisional Patent Application 
No. 60/396,577, filed July 16, 2002. All of the above ap- 
plications are hereby incorporated by reference. 
Field of Invention 

[0002] This invention generally relates to a system and method 
for using DNA recognition biometrics with a transponder- 
reader system, and more particularly, to configuring a 
transponder and transponder-reader for biometric secu- 
rity. 

Background of Invention 

[0003] Lii^e barcode and voice data entry, RFID is a contactless 
information acquisition technology. RFID systems are 
wireless, and are usually extremely effective in hostile en- 
vironments where conventional acquisition methods fail. 
RFID has established itself in a wide range of markets, 
such as, for example, the high-speed reading of railway 
containers, tracking moving objects such as livestock or 
automobiles, and retail inventory applications. As such, 
RFID technology has become a primary focus in auto- 



mated data collection, identification and analysis systems 
worldwide. 

[0004] Of late, companies are increasingly embodying RFID data 
acquisition technology in a fob or tag for use in complet- 
ing financial transactions. A typical fob includes a 
transponder and is ordinarily a self-contained device 
which may be contained on any portable form factor. In 
some instances, a battery may be included with the fob to 
power the transponder. In which case the internal circuitry 
of the fob (including the transponder) may draw its oper- 
ating power from the battery power source. Alternatively, 
the fob may exist independent of an internal power 
source. In this instance the internal circuitry of the fob 
(including the transponder) may gain its operating power 
directly from an RF interrogation signal. U.S. Patent No. 
5,053,774, issued to Schuermann, describes a typical 
transponder RF interrogation system which may be found 
in the prior art. The Schuermann patent describes in gen- 
eral the powering technology surrounding conventional 
transponder structures. U.S. Patent No. 4,739,328, dis- 
cusses a method by which a conventional transponder 
may respond to a RF interrogation signal. Other typical 
modulation techniques which may be used include, for 



example, ISO/IEC 14443 and the like. 
[0005] In the conventional fob powering technologies used, the 
fob is typically activated upon presenting the fob in an in- 
terrogation signal. In this regard, the fob may be activated 
irrespective of whether the user desires such activation. 
Inadvertent presentation of the fob may result in initiation 
and completion of an unwanted transaction. Thus, a fob 
system is needed which allows the fob user to control ac- 
tivation of the fob to limit transactions being undesirably 
completed. 

[0006] One of the more visible uses of the RFID technology is 
found in the introduction of Exxon/Mobil's Speedpass® 
and Shell's EasyPay® products. These products use 
transponders placed in a fob or tag which enables auto- 
matic identification of the user when the fob is presented 
at a Point of Sale (POS) device. Fob identification data is 
typically passed to a third-party server database, where 
the identification data is referenced to a customer (e.g., 
user) credit or debit account. In an exemplary processing 
method, the server seeks authorization for the transaction 
by passing the transaction and account data to an autho- 
rizing entity. Once authorization is received by the server, 
clearance is sent to the point of sale device for completion 



of the transaction. In this way, the conventional transac- 
tion processing method involves an indirect path which 
causes undue overhead due to the use of the third-party 
server. 

[0007] A need exists for a transaction authorization system which 
allows fob transactions to be authorized while eliminating 
the cost associated with using third-party servers. 

[0008] In addition, conventional fobs are limited in that they 

must be used in proximity to the Point of Sale device. That 
is, for fob activation, conventional fobs must be posi- 
tioned within the area of transmission cast by the RF in- 
terrogation signal. More particularly, conventional fobs 
are not effective for use in situations where the user 
wishes to conduct a transaction at a point of interaction 
such as a computer interface. 

[0009] Therefore, a need exists for a fob embodying RFID acqui- 
sition technology, which is capable of use at a point of in- 
teraction device and which is additionally capable of facil- 
itating transactions via a computer interface connected to 
a network (e.g., the Internet). 

[0010] Existing transponder-reader payment systems are also 

limited in that the conventional fob used in the systems is 
only responsive to one interrogation signal. Where multi- 



pie interrogation signals are used, the fob is only respon- 
sive to the interrogation signal to which it is configured. 
Thus, if the RFID reader of the system provides only an in- 
terrogation signal to which the fob is incompatible, the 
fob will not be properly activated. 

[0011] Therefore, a need exists for a fob which is responsive to 
more than one interrogation signal. 

[0012] Existing transponder-reader payment systems are addi- 
tionally limited in that the payment systems are typically 
linked to a funding source associated with the transpon- 
der which includes a predetermined spending limit. Thus 
no flexibility is provided in instances where the payment 
is requested which exceeds the predetermined spending 
limit. This is typically true in that traditional methods for 
processing a requested transaction involve comparing the 
transaction to the spending limit or to an amount stored 
in a preloaded value data file prior to providing transac- 
tion authorization to a merchant. 

[0013] Thus, a system is needed which processes transponder- 
reader payment requests irrespective of the spending limit 
assigned to an associated transponder-reader payment 
system funding source. 

[0014] Further, traditional transponder-reader systems do not 



permit the user to manage the system user account data. 
This is extremely problematic where the user wishes to 
change a transponder-reader system funding source to a 
source which provides more available spending room, or 
where changes are made to the user's status (e.g., change 
in address, phone number, email, etc.) for which the 
transponder-reader account provider wishes to readily 
update the user's account. 

[0015] Thus a need exists for a transponder-reader system which 
will allow the user limited access to the transponder- 
reader account for managing account data. 

[0016] Further still, existing transponder-reader systems do not 
usually permit means for automatically incenting the use 
of the fob associated with the system as opposed to the 
credit or charge card associated with the fob. That is, 
conventional transponder-reader systems do not provide 
a means for encouraging usage of the transponder reader 
system by encouraging use of the fob product since the 
present systems do not sufficiently distinguish between 
usage of a system transponder and a charge or credit card 
account associated with the transponder. 

[0017] Consequently, a need exists for a transponder-reader 
system which is capable of determining when a system 



transponder is used, and providing an incentive for sucli 
usage. 

[0018] Still further, present systems are limited in that the sys- 
tems are unable to track credit or charge card usage and 
fob usage for a single funding source. For example, in 
typical prior art systems, a fob may be linked to a speci- 
fied funding source (e.g., American Express, MasterCard, 
Visa, etc.) which may be used to provide funds for satis- 
faction of a transaction request. The funding source may 
additionally have a consumer credit or charge card which 
may be associated with the fob and which may be used for 
contact transactions. Where the credit or charge card is 
used, a statement reporting the card usage is provided to 
the card user. However, the reporting statement does not 
include a reporting of the fob product usage. Thus, a fob 
user is unable to adequately chart, analyze or compare 
fob usage to the usage of the associated card. This is es- 
pecially problematic where the funding source is used by 
more than one entity (e.g., spouses, multiple company 
personnel, etc.) or where one entity may use the fob and a 
separate entity may use the card associated with the fob. 

[0019] Thus, a need exists for a transponder-reader payment 

system which would permit reporting of the fob usage and 



the credit card usage in a single file. 
Summary of Invention 

[0020] Described herein is a system and method for using RFID 
technology to initiate and complete financial transactions. 
The transponder-reader payment system described herein 
may include a RFID reader operable to provide a RF inter- 
rogation signal for powering a transponder system, re- 
ceiving a transponder system RF signal, and providing 
transponder system account data relative to the transpon- 
der system RF signal. The transponder-reader payment 
system may include a RFID protocol/sequence controller 
in electrical communication with one or more interroga- 
tors for providing an interrogation signal to a transpon- 
der, a RFID authentication circuit for authenticating the 
signal received from the transponder, a serial or parallel 
interface for interfacing with a point of interaction device, 
and an USB or serial interface for use in personalizing the 
RFID reader and/or the transponder. The transponder- 
reader payment system may further include a fob includ- 
ing one or more transponders (e.g., modules) responsive 
to one or more interrogation signals and for providing an 
authentication signal for verifying that the transponder 
and/or the RFID reader are authorized to operate within 



the transponder-reader payment system. In this way, the 
fob may be responsive to multiple interrogation signals 
provided at different frequencies. Further, the fob may in- 
clude a USB or serial interface for use with a computer 
network or with the RFID reader. 

[0021] The RFID system and method according to the present in- 
vention may include a transponder which may be embod- 
ied in a fob, tag, card or any other form factor (e.g., wrist- 
watch, keychain, cell phone, etc.), which may be capable 
of being presented for interrogation. In that regard, al- 
though the transponder is described herein as embodied 
in a fob, the invention is not so limited. 

[0022] The system may further include a RFID reader configured 
to send a standing RFID recognition signal which may be 
transmitted from the RFID reader via radio frequency (or 
electromagnetic) propagation. The fob may be placed 
within proximity to the RFID reader such that the RFID 
signal may interrogate the fob and initialize fob identifi- 
cation procedures. 

[0023] In one exemplary embodiment, as a part of the identifica- 
tion process, the fob and the RFID reader may engage in 
mutual authentication. The RFID reader may identify the 
fob as including an authorized system transponder for re- 



ceiving encrypted information and storing tlie information 
on tlie fob memory. Similarly, the fob, upon interrogation 
by the RFID reader, may identify the RFID reader as autho- 
rized to receive the encrypted and stored information. 
Where the RFID reader and the fob successfully mutually 
authenticate, the fob may transmit to the RFID reader cer- 
tain information identifying the transaction account or ac- 
counts to which the fob is associated. The RFID reader 
may receive the information and forward the information 
to facilitate the completion of a transaction. In one exem- 
plary embodiment, the RFID reader may forward the infor- 
mation to a point of interaction device (e.g., POS or com- 
puter interface) for transaction completion. The mutual 
authorization process disclosed herein aids in ensuring 
fob transponder-reader payment system security. 

[0024] In another exemplary embodiment, the fob according to 
the present invention, includes means for completing 
transactions via a computer interface. The fob may be 
connected to the computer using a USB or serial interface 
fob account information may be transferred to the com- 
puter for use in completing a transaction via a network 
(e.g., the Internet). 

[0025] In yet another exemplary embodiment of the present in- 



vention, a system is provided which incents usage of the 
transponder-reader system transponder (e.g., fob). The 
system distinguishes between the usage of a fob and the 
usage of a charge or credit card sharing the same funding 
source as the fob. Where the fob is used, the system may 
provide incentives to the user based on criteria predeter- 
mined by the fob issuer. Additionally, where a preloaded 
fob system is used, the present invention recognizes when 
the associated fob preloaded value data file is loaded or 
reloaded with funds. The invention then may provide re- 
ward points based on the criteria associated with the 
loading or reloading action. Further, the system according 
to this invention may incent patronage of a merchant. In 
this case, the system may receive a fob transaction re- 
quest and incent the fob user based on a marker or other 
identifier correlated with the merchant. The marker may 
be included in the transaction identification, in a merchant 
identification provided with the transaction, or a combina- 
tion of both. 

[0026] In still another exemplary embodiment of the invention, a 
system is disclosed which enables the fob user/owner to 
manage the account associated with the fob. The user is 
provided limited access to all or a portion of the fob ac- 



count information stored on the account provider 
database for updating, for example, demographic infor- 
mation, account funding source, and/or account restric- 
tions (e.g., spending limits, personal identification num- 
ber, etc.). Access to all or a portion of the account may be 
provided to the user telephonically, via a network (e.g., 
online) or via offline communications. For example, the 
fob user may be provided access to a system which has 
delayed communications with the account provider 
database wherein such a system may include, for exam- 
ple, a kiosk which provides batch transmissions to the ac- 
count provider system. In this way, the fob user/owner 
may update his account information in real-time (e.g., 
telephonically or online) or at the time the account 
provider receives the updated information (e.g., offline). 
[0027] In a further exemplary embodiment, the present invention 
provides methods for processing a transaction request 
whereby the amount of the transaction request may be 
approved prior to requesting funding from the funding 
source and/or verifying that the amount for completing 
the transaction is available. In this way, the transaction 
may be approved provided the transaction and/or account 
meets certain predetermined authorization criteria. Once 



the criteria is met, the transaction is authorized and au- 
thorization is provided to the requesting agent (e.g., mer- 
chant), in one instance the payment for the transaction is 
requested from the funding source simultaneously to, or 
immediately following, the providing of the authorization 
to the merchant. In another instance, the payment for 
transactions is requested at a time period later than when 
the authorization is provided to the merchant. 

[0028] In yet another embodiment, the transponder, transpon- 
der-reader, and/or transponder-reader system are con- 
figured with a biometric security system. The biometric 
security system includes a transponder and a reader com- 
municating with the system. The biometric security sys- 
tem also includes a DNA scan sensor that detects biomet- 
ric samples and a device for verifying biometric samples. 

[0029] In yet another embodiment, the present invention dis- 
closes methods for proffering and processing DNA scan 
samples to facilitate authorization of transactions. 

[0030] These features and other advantages of the system and 

method, as well as the structure and operation of various 

exemplary embodiments of the system and method, are 

described below. 
Brief Description of Drawings 



[0031] The accompanying drawings, wherein lil<e numerals depict 
like elements, illustrate exemplary embodiments of the 
present invention, and together with the description, serve 
to explain the principles of the invention. In the drawings: 

[0032] FIG. lA illustrates an exemplary RFID-based system in ac- 
cordance with the present invention, wherein exemplary 
components used for fob transaction completion are de- 
picted; 

[0033] FIG. IB illustrates an exemplary personalization system in 
accordance with the present invention; 

[0034] FIG. 2 is a schematic illustration of an exemplary fob in 
accordance with the present invention; 

[0035] FIG. 3 is a schematic illustration of an exemplary RFID 
reader in accordance with the present invention; 

[0036] FIG. 4 is an exemplary flow diagram of an exemplary au- 
thentication process in accordance with the present in- 
vention; 

[0037] FIG. 5 is an exemplary flow diagram of an exemplary deci- 
sion process for a protocol/sequence controller in accor- 
dance with the present invention; 

[0038] FIGS. 6A-B are exemplary flow diagrams of a fob person- 
alization process in accordance with the present inven- 
tion; 



[0039] FIGS. 7A-B are exemplary flow diagrams of a RFID reader 
personalization process in accordance with the present 
invention; 

[0040] FIG. 8 is a flow diagram of an exemplary payment/ 

transaction process in accordance with the present inven- 
tion; 

[0041] FIG. 9 is another schematic illustration of an exemplary 
fob in accordance with the present invention; 

[0042] FIG. 10 is a depiction of an exemplary preloaded fob pay- 
ment/transaction process in accordance with the present 
invention; 

[0043] FIGS. IIA-B are depictions of an exemplary preloaded fob 
account reload process in accordance with the present in- 
vention; 

[0044] FIG. 12 is a depiction of an exemplary Direct Link pay- 
ment/transaction process in accordance with the present 
invention; 

[0045] FIG. 13 is a depiction of another exemplary payment/ 

transaction process in accordance with the present inven- 
tion; 

[0046] FIG. 14 is a depiction of an exemplary biometrics process 

in accordance with the present invention; 
[0047] FIG. 15 is another schematic illustration of an exemplary 



fob in accordance with the present invention; and 

[0048] FIG. 16 is another schematic illustration of an exemplary 

fob in accordance with the present invention. 
Detailed Description 

[0049] The present invention may be described herein in terms of 
functional block components, screen shots, optional se- 
lections and various processing steps. Such functional 
blocks may be realized by any number of hardware and/or 
software components configured to perform to specified 
functions. For example, the present invention may employ 
various integrated circuit components, (e.g., memory ele- 
ments, processing elements, logic elements, look-up ta- 
bles, and the like), which may carry out a variety of func- 
tions under the control of one or more microprocessors or 
other control devices. Similarly, the software elements of 
the present invention may be implemented with any pro- 
gramming or scripting language such as C, C++, Java, 
COBOL, assembler, PERL, extensible markup language 
(XML), JavaCard and MULTOS with the various algorithms 
being implemented with any combination of data struc- 
tures, objects, processes, routines or other programming 
elements. Further, it should be noted that the present in- 
vention may employ any number of conventional tech- 



niques for data transmission, signaling, data processing, 
networl< control, and the like. For a basic introduction on 
cryptography, review a text written by Bruce Schneier en- 
titled "Applied Cryptography: Protocols, Algorithms, and 
Source Code in C," published by John Wiley & Sons 
(second edition, 1996), herein incorporated by reference. 
[0050] In addition, many applications of the present invention 
could be formulated. The exemplary network disclosed 
herein may include any system for exchanging data or 
transacting business, such as the Internet, an intranet, an 
extranet, WAN, LAN, satellite communications, and/or the 
like. It is noted that the network may be implemented as 
other types of networks, such as an interactive television 
network (ITN). 

[0051] Where required, the system user may interact with the 

system via any input device such as, a keypad, keyboard, 
mouse, kiosk, personal digital assistant, handheld com- 
puter (e.g., Palm Pilot®, Blueberry®), cellular phone and/or 
the like). Similarly, the invention could be used in con- 
junction with any type of personal computer, network 
computer, work station, minicomputer, mainframe, or the 
like running any operating system such as any version of 
Windows, Windows NT, Windows 2000, Windows 98, Win- 



dows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris or the 
like. Moreover, although the invention may frequently be 
described as being implemented with TCP/IP communica- 
tions protocol, it should be understood that the invention 
could also be implemented using SNA, IPX, Appletalk, IPte, 
NetBIOS, OSI or any number of communications protocols. 
Moreover, the system contemplates, the use, sale, or dis- 
tribution of any goods, services or information over any 
network having similar functionality described herein. 

[0052] FIG. lA illustrates an exemplary RFID transaction system 
lOOA in accordance with the present invention, wherein 
exemplary components for use in completing a fob trans- 
action are depicted. In general, the operation of system 
lOOA may begin when a fob 102 is presented for pay- 
ment, and is interrogated by a RFID reader 104 or, alter- 
natively, interface 134. Fob 102 and RFID reader 104 may 
then engage in mutual authentication after which the 
transponder 114 may provide the transponder identifica- 
tion and/or account identifier to RFID reader 104 which 
may further provide the information to the merchant sys- 
tem 130 POS device 110. 

[0053] System lOOA may include fob 102 having a transponder 
114 and RFID reader 104 in RF communication with fob 



102. Although the present invention is described with re- 
spect to fob 102, the invention is not to be so limited. In- 
deed, system 100 may include any device having a 
transponder which is configured to communicate with 
RFID reader 104 via RF communication. Typical devices 
may include, for example, a key ring, tag, card, cell 
phone, wristwatch or any such form capable of being pre- 
sented for interrogation. 
[0054] RFID reader 104 may be configured to communicate using 
a RFID internal antenna 106. Alternatively, RFID reader 
104 may include an external antenna 108 for communica- 
tions with fob 102, where the external antenna may be 
made remote to RFID reader 104 using a suitable cable 
and/or data link 120. RFID reader 104 may be further in 
communication with a merchant system 130 via a data 
link 122. System lOOA may include a transaction comple- 
tion system including a point of interaction device such 
as, for example, a merchant point of sale (POS) device 110 
or a computer interface (e.g., user interface) 134. In one 
exemplary embodiment the transaction completion sys- 
tem may include a merchant system 130 including POS 
device 110 in communication with RFID reader 104 (via 
data link 122). As described more fully below, the trans- 



action completion system may include user interface 134 
connected to a network 136 and to the transponder via a 
USB connector 132. 
[0055] Although the point of interaction device is described 

herein with respect to a merchant point of sale (POS) de- 
vice, the invention is not to be so limited. Indeed, a mer- 
chant POS device is used herein by way of example, and 
the point of interaction device may be any device capable 
of receiving fob account data. In this regard, the POS may 
be any point of interaction device enabling the user to 
complete a transaction using fob 102. POS device 110 
may be in further communication with a customer inter- 
face 118 (via data link 128) for entering at least a cus- 
tomer identity verification information. In addition, POS 
device 110 may be in communication with a merchant 
host network 112 (via data link 124) for processing any 
transaction request. In this arrangement, information pro- 
vided by RFID reader 104 is provided to POS device 110 of 
merchant system 130 via data link 122. POS device 110 
may receive the information (and alternatively may receive 
any identity verifying information from customer interface 
118 via data link 128) and provide the information to host 
system 112 for processing. 



[0056] A variety of conventional communications media and pro- 
tocols may be used for data links 120, 122, 124, and 128. 
For example, data links 120, 122, 124, and 128 may be 
an Internet Service Provider (ISP) configured to facilitate 
communications over a local loop as is typically used in 
connection with standard modem communication, cable 
modem, dish networks, ISDN, Digital Subscriber Lines 
(DSL), or any wireless communication media. In addition, 
merchant system 130 including POS device 110 and host 
network 112 may reside on a local area network which in- 
terfaces to a remote network (not shown) for remote au- 
thorization of an intended transaction. Merchant system 
130 may communicate with the remote network via a 
leased line, such as aTl, D3 line, or the like. Such com- 
munications lines are described in a variety of texts, such 
as, "Understanding Data Communications," by Gilbert 
Held, which is incorporated herein by reference. 

[0057] An account number, as used herein, may include any 

identifier for an account (e.g., credit, charge debit, check- 
ing, savings, reward, loyalty, or the like) which may be 
maintained by a transaction account provider (e.g., pay- 
ment authorization center) and which may be used to 
complete a financial transaction. A typical account number 



(e.g., account data) may be correlated to a credit or debit 
account, loyalty account, or rewards account maintained 
and serviced by such entities as American Express®, Visa® 
and/or MasterCard® or the like. For ease in understand- 
ing, the present invention may be described with respect 
to a credit account. However, it should be noted that the 
invention is not so limited and other accounts permitting 
an exchange of goods and services for an account data 
value is contemplated to be within the scope of the 
present invention. 
[0058] In addition, the account number (e.g., account data) may 

be associated with any device, code, or other identifier/indi- 
cia suitably configured to allow the consumer to interact 
or communicate with the system, such as, for example, 
authorization/access code, personal identification number 
(PIN), Internet code, digital certificate, biometric data, 
and/or other identification indicia. The account number 
may be optionally located on a rewards card, charge card, 
credit card, debit card, prepaid card, telephone card, 
smart card, magnetic stripe card, bar code card, and/or 
the like. The account number may be distributed and 
stored in any form of plastic, electronic, magnetic, and/or 
optical device capable of transmitting or downloading 



data to a second device. A customer account number may 
be, for example, a sixteen-digit credit card number, al- 
though each credit provider has its own numbering sys- 
tem, such as the fifteen-digit numbering system used by 
American Express®. Each company's credit card numbers 
comply with that company's standardized format such 
that the company using a sixteen-digit format will gener- 
ally use four spaced sets of numbers, as represented by 
the number "0000 0000 0000 0000". In a typical example, 
the first five to seven digits are reserved for processing 
purposes and identify the issuing bank, card type and, 
etc. In this example, the last sixteenth digit is used as a 
sum check for the sixteen-digit number. The intermediary 
eight-to-ten digits are used to uniquely identify the cus- 
tomer. The account number stored as Track 1 and Track 2 
data as defined in ISO/IEC 7813, and further may be made 
unique to fob 102. In one exemplary embodiment, the ac- 
count number may include a unique fob serial number 
and user identification number, as well as specific appli- 
cation applets. The account number may be stored in fob 
102 inside a database 214, as described more fully below. 
Database 214 may be configured to store multiple ac- 
count numbers issued to fob 102 user by the same or dif- 



ferent account providing institutions. Where the account 
data corresponds to a loyalty or rewards account, 
database 214 may be configured to store the attendant 
loyalty or rewards points data. 

[0059] FIG. 2 illustrates a block diagram of the many functional 
blocks of an exemplary fob 102 in accordance with the 
present invention. Fob 102 may be a RFID fob 102 which 
may be presented by the user to facilitate an exchange of 
funds or points, etc., for receipt of goods or services. As 
described herein, by way of example, fob 102 may be a 
RFID fob which may be presented for facilitating payment 
for goods and/or services. 

[0060] Fob 102 may include an antenna 202 for receiving an in- 
terrogation signal from RFID reader 104 via antenna 106 
(or alternatively, via external antenna 108). Fob antenna 
202 may be in communication with a transponder 114. In 
one exemplary embodiment, transponder 114 may be a 
13.56 MHz transponder compliant with the ISO/IEC 14443 
standard, and antenna 202 may be of the 13 MHz variety. 
Transponder 114 may be in communication with a 
transponder compatible modulator/demodulator 206 
configured to receive the signal from transponder 114 
and configured to modulate the signal into a format read- 



able by any later connected circuitry. Further, modulator/ 
demodulator 206 may be configured to format (e.g., de- 
modulate) a signal received from the later connected cir- 
cuitry in a format compatible with transponder 114 for 
transmitting to RFID reader 104 via antenna 202. For ex- 
ample, where transponder 114 is of the 13.56 MHz vari- 
ety, modulator/demodulator 206 may be ISO/IEC 
14443-2 compliant. 

[0061] Modulator/demodulator 206 may be coupled to a proto- 
col/sequence controller 208 for facilitating control of the 
authentication of the signal provided by RFID reader 104, 
and for facilitating control of the sending of fob 102 ac- 
count number. In this regard, protocol/sequence con- 
troller 208 may be any suitable digital or logic driven cir- 
cuitry capable of facilitating determination of the se- 
quence of operation for fob 102 inner-circuitry. For ex- 
ample, protocol/sequence controller 208 may be config- 
ured to determine whether the signal provided by RFID 
reader 104 is authenticated, and thereby providing to 
RFID reader 104 the account number stored on fob 102. 

[0062] Protocol/sequence controller 208 may be further in com- 
munication with authentication circuitry 210 for facilitat- 
ing authentication of the signal provided by RFID reader 



104. Authentication circuitry may be furtlier in communi- 
cation witli a non-volatile secure memory database 212. 
Secure memory database 212 may be any suitable ele- 
mentary file system such as that defined by ISO/IEC 
7816-4 or any other elementary file system allowing a 
lookup of data to be interpreted by the application on the 
chip. Database 212 may be any type of database, such as 
relational, hierarchical, object-oriented, and/or the like. 
Common database products that may be used to imple- 
ment the databases include DB2 by IBM (White Plains, NY), 
any of the database products available from Oracle Cor- 
poration (Redwood Shores, CA), Microsoft Access or 
MSSQL by Microsoft Corporation (Redmond, Washington), 
or any other database product. Database 212 may be or- 
ganized in any suitable manner, including as data tables 
or lookup tables. Association of certain data may be ac- 
complished through any data association technique 
known and practiced in the art. For example, the associa- 
tion may be accomplished either manually or automati- 
cally. Automatic association techniques may include, for 
example, a database search, a database merge, GREP, 
ACREP, SQL, and/or the like. The association step may be 
accomplished by a database merge function, for example. 



using a "key field" in eacli of tlie manufacturer and retailer 
data tables. A "key field" partitions the database according 
to the high-level class of objects defined by the key field. 
For example, a certain class may be designated as a key 
field in both the first data table and the second data table, 
and the two data tables may then be merged on the basis 
of the class data in the key field. In this embodiment, the 
data corresponding to the key field in each of the merged 
data tables is preferably the same. However, data tables 
having similar, though not identical, data in the key fields 
may also be merged by using AGREP, for example. 
[0063] The data may be used by protocol/sequence controller 

208 for data analysis and used for management and con- 
trol purposes, as well as security purposes. Authentication 
circuitry may authenticate the signal provided by RFID 
reader 104 by association of the RFID signal to authenti- 
cation keys stored on database 212. Encryption circuitry 
may use keys stored on database 212 to perform encryp- 
tion and/or decryption of signals sent to or from RFID 
reader 104. 

[0064] In addition, protocol/sequence controller 208 may be in 
communication with a database 214 for storing at least 
fob 102 account data, and a unique fob 102 identification 



code. Protocol/sequence controller 208 may be config- 
ured to retrieve the account number from database 214 as 
desired. Database 214 may be of the same configuration 
as database 212 described above. The fob account data 
and/or unique fob identification code stored on database 
214 may be encrypted prior to storage. Thus, where pro- 
tocol/sequence controller 208 retrieves the account data, 
and or unique fob identification code from database 214, 
the account number may be encrypted when being pro- 
vided to RFID reader 104. Further, the data stored on 
database 214 may include, for example, an unencrypted 
unique fob 102 identification code, a user identification. 
Track 1 and 2 data, as well as specific application applets. 
[0065] Fob 102 may be configured to respond to multiple inter- 
rogation frequency transmissions provided by RFID reader 
104. That is, as described more fully below, RFID reader 
104 may provide more than one RF interrogation signal. In 
this case, fob 102 may be configured to respond to the 
multiple frequencies by including in fob 102 one or more 
additional RF signal receiving/transmitting units 226. RF 
signal receiving/transmitting unit 226 may include an an- 
tenna 218 and transponder 220 where antenna 218 and 
transponder 220 are compatible with at least one of the 



additional RF signals provided by RFID reader 104. For ex- 
ample, in one exemplary embodiment, fob 102 may in- 
clude a 134 KHz antenna 218 configured to communicate 
with a 134 KHz transponder 220. In this exemplary con- 
figuration, an ISO/IEC 14443-2 compliant modulator/ 
demodulator may not be required. Instead, the 134 KHz 
transponder may be configured to communicate directly 
with protocol/sequence controller 208 for transmission 
and receipt of authentication and account number signals 
as described above. 
[0066] In another embodiment, fob 102 may further include a 
universal serial bus (USB) connector 132 for interfacing 
fob 102 to a user interface 134. User interface 134 may 
be further in communication with POS device 110 via net- 
work 136. Network 136 may be the Internet, an intranet, 
or the like as is described above with respect to network 
112. Further, user interface 134 may be similar in con- 
struction to any conventional input devices and/or com- 
puting systems aforementioned for permitting the system 
user to interact with the system. In one exemplary em- 
bodiment, fob 102 may be configured to facilitate online 
Internet payments. A USB converter 222 may be in com- 
munication with a USB connector 232 for facilitating the 



transfer of information between tlie modulator/demod- 
ulator 206 and USB connector 132. Alternatively, USB con- 
verter 222 may be in communication with protocol/se- 
quence controller 208 to facilitate the transfer of informa- 
tion between protocol/sequence controller 208 and USB 
connector 132. 

[0067] Where fob 102 includes a USB connector 132, fob 102 
may be in communication with, for example, a USB port 
on user interface 134. The information retrieved from fob 
102 may be compatible with credit card and/or smart card 
technology enabling usage of interactive applications on 
the Internet. No RFID reader may be required in this em- 
bodiment since the connection to POS device 110 may be 
made using a USB port on user interface 134 and network 
136. 

[0068] Fob 102 may include means for enabling activation of the 
fob by the user. In one exemplary embodiment, a switch 
230 which may be operated by the user of fob 102. Switch 
230 on fob 102 may be used to selectively or inclusively 
activate fob 102 for particular uses. In this context, the 
term "selectively" may mean that switch 230 enables the 
user to place fob 102 in a particular operational mode. For 
example, the user may place fob 102 in a mode for en- 



abling purchase of a good or of a service using a selected 
account number. Alternatively, the fob may be placed in a 
mode as such that the fob account number is provided by 
USB port 132 (or serial port) only and the fob transponder 
114 is disabled. In addition, the term "inclusively" may 
mean that fob 102 is placed in an operational mode per- 
mitting fob 102 to be responsive to the RF interrogation 
and interrogation via USB connector 132. In one particular 
embodiment, switch 230 may remain in an OFF position 
ensuring that one or more applications or accounts asso- 
ciated with fob 102 are non-reactive to any commands is- 
sued by RFID reader 104. As used herein, the OFF position 
may be termed the "normal" position of activation switch 
230, although other normal positions are contemplated. 
[0069] In another exemplary embodiment, when switch 230 is 
moved from the OFF position, fob 102 may be deemed 
activated by the user. That is, switch 230 may activate in- 
ternal circuitry in fob 102 for permitting the fob to be re- 
sponsive to RF signals (e.g., commands from RFID reader 
104). In this way, switch 230 may facilitate control of the 
active and inactive states of fob 102. Such control in- 
creases the system security by preventing inadvertent or 
illegal use of fob 102. 



[0070] In one exemplary embodiment, switch 230 may be a sim- 
ple mechanical device in communication with circuitry 
which may electrically prevent the fob from being pow- 
ered by a RFID reader. That is, when switch 230 is in its 
normal position, switch 230 may provide a short to fob 
102 internal circuitry, preventing fob 102 from being re- 
sponsive to interrogation by RF or via the USB connector 
230. In this arrangement, switch 230 may be, for exam- 
ple, a "normally closed" (NC) configured switch, which 
may be electrically connected to the antenna 202 at the 
interface of the antenna 202 and transponder 114. Switch 
230 may be depressed, which may open switch 230 fully 
activating the antenna 202. 

[0071] In yet another exemplary embodiment, fob 102 may in- 
clude a biometric sensor and biometric membrane config- 
ured to operate as switch 230 and activate fob 102 when 
provided biometric signal from fob 102 user. Such bio- 
metric signal may be the digital reading of a fingerprint, 
thumbprint, or the like. Typically, where biometric cir- 
cuitry is used, the biometric circuitry may be powered by 
an internal voltage source (e.g., battery). In this case, the 
switch may not be a simple mechanical device, but a 
switch which is powered. In yet another exemplary em- 



bodiment, switch 230 may be battery powered though no 
biometric circuitry is present in fob 102. 

[0072] In yet another embodiment, switch 230 may be a logic 
switch. Where switch 230 is a logic switch, switch 230 
control software may be read from the sequence con- 
troller 208 to selectively control the activation of the vari- 
ous fob 102 components. 

[0073] FIG. 3 illustrates an exemplary block diagram of RFID 

reader 104 in accordance with an exemplary embodiment 
of the present invention. RFID reader 104 includes, for 
example, an antenna 106 coupled to a RF module 302, 
which is further coupled to a control module 304. In addi- 
tion, RFID reader 104 may include an antenna 108 posi- 
tioned remotely from RFID reader 104 and coupled to 
RFID reader 104 via a suitable cable 120, or other wire or 
wireless connection. 

[0074] module 302 and antenna 106 may be suitably config- 
ured to facilitate communication with fob 102. Where fob 
102 is formatted to receive a signal at a particular RF fre- 
quency, RF module 302 may be configured to provide an 
interrogation signal at that same frequency. For example, 
in one exemplary embodiment, fob 102 may be config- 
ured to respond to an interrogation signal of about 13.56 



MHz. In this case, RFID antenna 106 may be 13 MHz and 
may be configured to transmit an interrogation signal of 
about 13.56 MHz. That is, fob 102 may be configured to 
include a first and second RF module (e.g., transponder) 
where the first module may operate using a 134 kHz fre- 
quency and the second RF module may operate using a 
13.56 MHz frequency. RFID reader 104 may include two 
receivers which may operate using the 134 kHz frequency, 
the 13.56 MHz frequency or both. When the reader 104 is 
operating at 134 kHz frequency, only operation with the 
134 kHz module on fob 102 may be possible. When the 
reader 104 is operating at the 13.56 MHz frequency, only 
operation with the 13.56 MHz module on fob 102 may be 
possible. Where the reader 104 supports both a 134 kHz 
frequency and a 13.56 MHz RF module, fob 102 may re- 
ceive both signals from the reader 104. In this case, fob 
102 may be configured to prioritize selection of the one 
or the other frequency and reject the remaining fre- 
quency. Alternatively, the reader 104 may receive signals 
at both frequencies from the fob upon interrogation. In 
this case, the reader 104 may be configured to prioritize 
selection of one or the other frequency and reject the re- 
maining frequency. 



[0075] Further, protocol/sequence controller 314 may include an 
optional feedback function for notifying the user of the 
status of a particular transaction. For example, the op- 
tional feedback may be in the form of an LED, LED screen 
and/or other visual display which is configured to light up 
or display a static, scrolling, flashing and/or other mes- 
sage and/or signal to inform fob 102 user that the trans- 
action is initiated (e.g., fob is being interrogated), the fob 
is valid (e.g., fob is authenticated), transaction is being 
processed, (e.g., fob account number is being read by 
RFID reader) and/or the transaction is accepted or denied 
(e.g., transaction approved or disapproved). Such an op- 
tional feedback may or may not be accompanied by an 
audible indicator (or may present the audible indicator 
singly) for informing fob 102 user of the transaction sta- 
tus. The audible feedback may be a simple tone, multiple 
tones, musical indicator, and/or voice indicator config- 
ured to signify when the fob 102 is being interrogated, 
the transaction status, or the like. 

[0076] RFID antenna 106 may be in communication with a 

transponder 306 for transmitting an interrogation signal 
and receiving at least one of an authentication request 
signal and/or an account data from fob 102. Transponder 



306 may be of similar description as transponder 114 of 
FIG. 2. In particular, transponder 306 may be configured 
to send and/or receive RF signals in a format compatible 
with antenna 202 in similar manner as was described with 
respect to fob transponder 114. For example, where 
transponder 306 is 13.56 MHz RF rated antenna 202 may 
be 13.56 MHz compatible. Similarly, where transponder 
306 is ISO/IEC 14443 rated, antenna 106 may be ISO/IEC 
14443 compatible. 

[0077] module 302 may include, for example, transponder 
306 in communication with authentication circuitry 308 
which may be in communication with a secure database 
310. Authentication circuitry 308 and database 310 may 
be of similar description and operation as described with 
respect to authentication circuitry 210 and secure memory 
database 212 of FIG. 2. For example, database 310 may 
store data corresponding to fob 102 which are authorized 
to transact business over system 100. Database 310 may 
additionally store RFID reader 104 identifying information 
for providing to fob 102 for use in authenticating whether 
RFID reader 104 is authorized to be provided the fob ac- 
count number stored on fob database 214. 

[0078] Authentication circuitry 308 may be of similar description 



and operation as authentication circuitry 210. Tliat is, au- 
tlientication circuitry 308 may be configured to authenti- 
cate the signal provided by fob 102 in similar manner that 
authentication circuitry 210 may be configured to authen- 
ticate the signal provided by RFID reader 104. As is de- 
scribed more fully below, fob 102 and RFID reader 104 
engage in mutual authentication. In this context, "mutual 
authentication" may mean that operation of the system 
100 may not take place until fob 102 authenticates the 
signal from RFID reader 104, and RFID reader 104 authen- 
ticates the signal from fob 102. 
[0079] FIG. 4 is a flowchart of an exemplary authentication pro- 
cess in accordance with the present invention. The au- 
thentication process is depicted as one-sided. That is, the 
flowchart depicts the process of RFID reader 104 authen- 
ticating fob 102, although similar steps may be followed 
in the instance that fob 102 authenticates RFID reader 
104. 

[0080] As noted, database 212 may store security keys for en- 
crypting or decrypting signals received from RFID reader 
104. In an exemplary authentication process, where RFID 
reader 104 is authenticating fob 102, RFID reader 104 
may provide an interrogation signal to fob 102 (step 402). 



The interrogation signal may include a random code gen- 
erated by the RFID reader authentication circuit 210, 
which is provided to fob 102 and which is encrypted using 
an unique encryption key corresponding to fob 102 
unique identification code. For example, protocol/se- 
quence controller 314 may provide a command to activate 
the authentication circuitry 308. Authentication circuitry 
308 may provide from database 310 a fob interrogation 
signal including a random number as a part of the au- 
thentication code generated for each authentication sig- 
nal. The authentication code may be an alphanumeric 
code which is recognizable (e.g., readable) by RFID reader 
104 and fob 102. The authentication code may be pro- 
vided to fob 102 via the RFID RF interface 306 and an- 
tenna 106 (or alternatively antenna 108). 
[0081] Fob 102 receives the interrogation signal (step 404). The 
interrogation signal including the authorization code may 
be received at the RF interface 114 via antenna 202. Once 
fob 102 is activated, the interrogation signal including the 
authorization code may be provided to the modulator/ 
demodulator circuit 206 where the signal may be demod- 
ulated prior to providing the signal to protocol/sequence 
controller 208. Protocol/sequence controller 208 may rec- 



ognize the interrogation signal as a request for authenti- 
cation of fob 102, and provide the authentication code to 
authentication circuit 210. Fob 102 may then encrypt the 
authentication code (step 406). In particular, encryption 
may be done by authentication circuit 210, which may re- 
ceive the authentication code and encrypt the code prior 
to providing the encrypted authentication code to proto- 
col/sequence controller 208. Fob 102 may then provide 
the encrypted authentication code to RFID reader 104 
(step 408). That is, the encrypted authentication code may 
be provided to RFID reader 104 via modulator/demod- 
ulator circuit 206, RF interface 114 (e.g., transponder 114) 
and antenna 202. 
[0082] RFID reader 104 may then receive the encrypted authenti- 
cation code and decrypt it (step 410). That is, the en- 
crypted authentication code may be received at antenna 
106 and RF interface 306 and may be provided to authen- 
tication circuit 308. Authentication circuit 308 may be 
provided a security authentication key (e.g., transponder 
system decryption key) from database 310. The authenti- 
cation circuit may use the authentication key to decrypt 
(e.g., unlock) the encrypted authorization code. The au- 
thentication key may be provided to the authentication 



circuit based on fob 102 unique identification code. For 
example, the encrypted autlientication code may be pro- 
vided along with the unique fob 102 identification code. 
The authentication circuit may receive fob 102 unique 
identification code and retrieve from the database 310 a 
transponder system decryption key correlative to the 
unique fob 102 identification code for use in decrypting 
the encrypted authentication code. 
[0083] Once the authentication code is decrypted, the decrypted 
authentication code is compared to the authentication 
code provided by RFID reader 104 at step 402 (step 412) 
to verify its authenticity. If the decrypted authorization 
code is not readable (e.g., recognizable) by the authenti- 
cation circuit 308, fob 102 is deemed to be unauthorized 
(e.g., unverified) (step 418) and the operation of system 
100 is terminated (step 420). Contrarily, if the decrypted 
authorization code is recognizable (e.g., verified) by fob 
102, the decrypted authorization code is deemed to be 
authenticated (step 414), and the transaction is allowed to 
proceed (step 416). In one particular embodiment, the 
proceeding transaction may mean that fob 102 may au- 
thenticate RFID reader 104 prior to RFID reader 104 au- 
thenticating fob 102, although, it should be apparent that 



RFID reader 104 may authenticate fob 102 prior to fob 
102 authenticating RFID reader 104. 

[0084] It should be noted that in an exemplary verification pro- 
cess, the authorization circuit 308 may determine whether 
the unlocked authorization code is identical to the autho- 
rization code provided in step 402. If the codes are not 
identical then fob 102 is not authorized to access system 
100. Although, the verification process is described with 
respect to identicality, identicality is not required. For ex- 
ample, authentication circuit 308 may verify the decrypted 
code through any protocol, steps, or process for deter- 
mining whether the decrypted code corresponds to an au- 
thorized fob 102. 

[0085] Authentication circuitry 308 may additionally be in com- 
munication with a protocol/sequence controller 314 of 
similar operation and description as protocol/sequence 
controller 208 of FIG. 2. That is, protocol/sequence device 
controller 314 may be configured to determine the order 
of operation of RFID reader 104 components. For exam- 
ple, FIG. 5 illustrates and exemplary decision process un- 
der which protocol/sequence controller 314 may operate. 
Protocol/sequence controller 314 may command the dif- 
ferent components of RFID reader 104 based on whether 



fob 102 is present (step 502). For example, if fob 102 is 
not present, then protocol/sequence controller 314 may 
command RFID reader 104 to provide an uninterrupted 
interrogation signal (step 504). That is, the protocol/se- 
quence controller may command the authentication circuit 
308 to provide an uninterrupted interrogation signal until 
the presence of fob 102 is realized. If fob 102 is present, 
protocol/sequence controller 314 may command RFID 
reader 104 to authenticate fob 102 (step 506). 
[0086] As noted above, authentication may mean that protocol/ 
sequence controller 314 may command the authentication 
circuit 308 to provide fob 102 with an authorization code. 
If a response is received from fob 102, protocol/sequence 
controller may determine if the response is a response to 
RFID reader 104 provided authentication code, or if the 
response is a signal requiring authentication (step 508). If 
the signal requires authentication, then protocol/se- 
quence controller 314 may activate the authentication cir- 
cuit as described above (step 506). On the other hand, if 
fob 102 signal is a response to the provided authentica- 
tion code, then protocol/sequence controller 314 may 
command RFID reader 104 to retrieve the appropriate se- 
curity key for enabling recognition of the signal (step 



510). That is, protocol/sequence controller 314 may com- 
mand the authentication circuit 308 to retrieve from 
database 310 a security key (e.g., transponder system de- 
cryption key), unlock the signal, and compare the signal 
to the signal provided by RFID reader 104 in the authenti- 
cation process (e.g., step 506). If the signal is recognized, 
protocol/sequence controller 314 may determine that fob 
102 is authorized to access the system 100. If the signal 
is not recognized, then fob 102 is considered not autho- 
rized. In which case, protocol/sequence controller 314 
may command the RFID controller to interrogate for au- 
thorized fobs (step 504). 
[0087] Once the protocol/sequence controller determines that 
fob 102 is authorized, protocol/sequence controller 314 
may seek to determine if additional signals are being sent 
by fob 102 (step 514). If no additional signal is provided 
by fob 102, then protocol/sequence controller 314 may 
provide all the components of RFID reader 104 to remain 
idle until such time as a signal is provided (step 516). 
Contrarily, where an additional fob 102 signal is provided, 
protocol/sequence controller 314 may determine if fob 
102 is requesting access to the merchant point of sale 
terminal 110 (e.g., POS device) or if fob 102 is attempting 



to interrogate RFID reader 104 for return (e.g., mutual) 
authorization (step 518). Where fob 102 is requesting ac- 
cess to a merchant point of sale terminal 110, protocol/ 
sequence controller 314 may command RFID reader 104 
to open communications with point of sale terminal 110 
(step 524). In particular, protocol/sequence controller 314 
may command the point of sale terminal communications 
interface 312 to become active, permitting transfer of 
data between RFID reader 104 and the merchant point of 
sale terminal 110. 
[0088] On the other hand, if the protocol/sequence controller 
determines that fob 102 signal is a mutual interrogation 
signal, then the protocol/sequence controller may com- 
mand RFID reader 104 to encrypt the signal (step 520). 
Protocol/sequence controller 314 may command the en- 
cryption authentication circuit 318 to retrieve from 
database 320 the appropriate encryption key in response 
to fob 102 mutual interrogation signal. Protocol/sequence 
controller 314 may then command RFID reader 104 to 
provide the encrypted mutual interrogation signal to fob 
102. Protocol/sequence controller 314 may command the 
authentication circuit 318 to provide an encrypted mutual 
interrogation signal for fob 102 to mutually authenticate. 



Fob 102 may then receive the encrypted mutual interro- 
gation signal and retrieve from authentication circuitry 
212 a RFID reader decryption key. 

[0089] Although an exemplary decision process of protocol/se- 
quence controller 314 is described, it should be under- 
stood that a similar decision process may be undertaken 
by protocol/sequence controller 208 in controlling the 
components of fob 102. Indeed, as described above, pro- 
tocol/sequence controller 314 may have similar operation 
and design as protocol/sequence controller 208. In addi- 
tion, to the above, protocol/sequence controllers 208 and 
314 may incorporate in the decision process appropriate 
commands for enabling USB interfaces 222 and 316, when 
the corresponding device is so connected. 

[0090] Encryption/decryption component 318 may be further in 
communication with a secure account number database 
320 which stores the security keys necessary for decrypt- 
ing the encrypted fob account number. Upon appropriate 
request from protocol/sequence controller 314, encryp- 
tion/decryption component (e.g., circuitry 318) may re- 
trieve the appropriate security key, decrypt the fob ac- 
count number and forward the decrypted account number 
to protocol sequence controller 314 in any format read- 



able by any later connected POS device 110. In one exem- 
plary embodiment, the account number may be forwarded 
in a conventional magnetic stripe format compatible with 
the ISO/IEC 7813 standard. That is, in accordance with the 
invention, there is no need to translate or correlate the 
account number to traditional magnetic stripe format as is 
done with the prior art. The invention processes the 
transaction request directly, as if the card associated with 
the account has been presented for payment. 
[0091] Upon receiving the account number in magnetic stripe 

format, protocol/sequence controller 314 may forward the 
account number to POS device 110 via a communications 
interface 312 and data link 122, as best shown in Figure 
1. POS device 110 may receive the decrypted account 
number and forward the magnetic stripe formatted ac- 
count number to a merchant network 112 for processing 
under the merchant's business as usual standard. In this 
way, the present invention eliminates the need of a third- 
party server. Further, where POS device 110 receives a re- 
sponse from network 112 (e.g., transaction authorized or 
denied), protocol/sequence controller 314 may provide 
the network response to the RF module 302 for optically 
and/or audibly communicating the response to fob 102 



user. 

[0092] RFID reader 104 may additionally include a USB interface 
316, in communication with the protocol/sequence con- 
troller 314. In one embodiment, the USB interface may be 
a RS22 serial data interface. Alternatively, RFID reader 104 
may include a serial interface such as, for example, a 
RS232 interface in communication with the protocol/se- 
quence controller 314. The USB connector 316 may be in 
communication with a personalization system 116 (shown 
in FIG. IB) for initializing RFID reader 104 to system 100 
application parameters. That is, prior to operation of sys- 
tem 100, RFID reader 104 may be in communication with 
personalization system 116 for populating database 310 
with a listing of security keys belonging to authorized 
fobs 102, and for populating database 320 with the secu- 
rity keys to decrypt fob 102 account numbers placing the 
account numbers in ISO/IEC 7813 format. In this way, 
RFID reader 104 may be populated with a unique identifier 
(e.g., serial number) which may be used by fob authenti- 
cation circuitry 210 to determine if RFID reader 104 is au- 
thorized to receive fob 102 encrypted account number. 

[0093] FIG. IB illustrates an exemplary personalization system 
lOOB, in accordance with the present invention. In gen- 



eral, typical personalization system lOOB may be any sys- 
tem for initializing RFID reader 104 and fob 102 for use in 
system lOOA. With reference to FIG. IB, the similar per- 
sonalization process for fob 102 may be illustrated. For 
example, personalization system 116 may be in commu- 
nication with fob 102 via RF ISO 14443 interface 114 for 
populating fob database 212 with the security keys for fa- 
cilitating authentication of the unique RFID reader 104 
identifier. In addition, personalization system 116 may 
populate on database 212 a unique fob 102 identifier for 
use by RFID reader 104 in determining whether fob 102 is 
authorized to access system 100. Personalization system 
116 may populate (e.g., inject) the encrypted fob 102 ac- 
count number into fob database 214 for later providing to 
an authenticated RFID reader 104. 
[0094] In one exemplary embodiment, personalization system 
116 may include any standard computing system as de- 
scribed above. For example, personalization system 116 
may include a standard personal computer containing a 
hardware security module operable using any conven- 
tional graphic user interface. Prior to populating the secu- 
rity key information account number and unique identify- 
ing information into fob 102 or RFID reader 104, the 



hardware security module may authenticate fob 102 and 
RFID reader 104 to verify that the components are autho- 
rized to receive the secure information. 
[0095] FIGS. 6A-B illustrate an exemplary flowchart of a person- 
alization procedure which may be used to personalize fob 
102 and/or RFID reader 104. Although the following de- 
scription discusses mainly personalization of fob 102, 
RFID reader 104 may be personalized using a similar pro- 
cess. The personalization process, which occurs between 
the personalization system 116 and the device to be per- 
sonalized (e.g., fob 102 or RFID reader 104), may begin, 
for example at step 602. Mutual authentication may occur 
between the personalization system 116 and the device to 
be authenticated in much the same manner as was de- 
scribed above with regard to fob 102 mutually authenti- 
cating with RFID reader 104. That is, personalization sys- 
tem 116 may transmit a personalization system 116 iden- 
tifier to the device to be authenticated which is compared 
by the device authentication circuitry 210, 308 against 
personalization system identifiers stored in the device 
database 212, 310. Where a match does not occur (step 
604), the personalization process may be aborted (step 
612). Where a match occurs (step 604), the personaliza- 



tion system may prepare a personalization file to be pro- 
vided to the device to be personalized (step 606). If the 
personalization system is operated manually, the person- 
alization file may be entered into the personalization sys- 
tem 116 using any suitable system interface such as, for 
example, a keyboard (step 606). Where the personaliza- 
tion system 116 operator elects to delay the preparation 
of the personalization files, the system 116 may abort the 
personalization process (step 610). In this context, the 
personalization file may include the unique fob 102 or 
RFID reader 104 identifier, security key for loading into 
database 212 and 310, and/or security keys for decrypt- 
ing a fob account number which may be loaded in 
database 320. 

[0096] Fob 102 may be personalized by direct connection to the 
personalization system 116 via RF ISO/IEC 14443 inter- 
face 114, or fob 102 may be personalized using RFID 
reader 104. Personalization system 116 and RFID reader 
104 may engage in mutual authentication and RFID reader 
104 may be configured to transmit the fob personaliza- 
tion file to fob 102 via RF. Once fob 102 is presented to 
RFID reader 104 (steps 608, 614) for personalization, fob 
102 and RFID reader 104 may engage in mutual authenti- 



cation (step 614). Where fob 102 is not presented to RFID 
reader 104 for personalization, tlie personalization pro- 
cess may be aborted (step 610). 

[0097] If fob 102 is detected, the personalization system 116 
may create as a part of the personalization file, a unique 
identifier for providing to fob 102 (step 616). The identi- 
fier is unique in that one identifier may be given only to a 
single fob. That is, no other fob may have that same iden- 
tifier. The fob may then be configured and loaded with 
that identifier (step 618). 

[0098] The encrypted fob 102 account number may be populated 
into fob 102 in the same manner as is described with re- 
spect to fob 102 unique identifier. That is, personalization 
system 116 may pre-encrypt the account data (step 620) 
and inject the encrypted account into fob database 214 
(step 622). The encrypted account data may be loaded 
(e.g., injected) into fob 102 using RFID reader 104 as dis- 
cussed above. 

[0099] Once the personalization file is populated into fob 102, 

the populated information is irreversibly locked to prevent 
alteration, unauthorized reading and/or unauthorized ac- 
cess (step 624). Personalization system 116 may then cre- 
ate a log of the personalization file information for later 



access and analysis by the personalization system 116 
user (step 626). 

[0100] It should be noted that in the event the personalization 
process is compromised or interrupted (step 628), per- 
sonalization system 116 may send a security alert to the 
user (step 630) and the personalization process may be 
aborted (step 612). On the other hand, where no such 
compromising or interruption exists, personalization sys- 
tem 116 may be prepared to begin initialization on a sec- 
ond device to be personalized (step 632). 

[0101] FIGS. 7A-B illustrate another exemplary embodiment of a 
personalization process which may be used to personalize 
RFID reader 104. RFID reader 104 may be in communica- 
tion with a personalization system 116 via RFID reader 
USB connection 316 (step 702). Once connected, person- 
alization system 116 may establish communications with 
RFID reader 104 and RFID reader 104 may provide per- 
sonalization system 116 any RFID reader 104 identifica- 
tion data presently stored on RFID reader 104 (step 704). 
In accordance with step 708, where RFID reader 104 is 
being personalized for the first time (step 706) RFID 
reader 104 and personalization system 116 may engage 
in mutual authentication as described above with respect 



to FIGS. 6A-B. After the mutual authentication Is com- 
plete, personalization system 116 may verify that RFID 
reader 104 is properly manufactured or configured to op- 
erate within system 100. The verification may Include 
evaluating the operation of RFID reader 104 by determin- 
ing if the RFID reader will accept predetermined default 
settings. That is, personalization system 116 may then 
provide RFID reader 104 a set of default settings (step 
708) and determine If RFID reader 104 accepts those set- 
tings (step 712). If RFID reader 104 does not accept the 
default settings, personalization system 116 may abort 
the personalization process (step 714). 

[0102] If personalization system 116 determines that the person- 
alization process is not the first personalization process 
undertaken by RFID reader 104 (step 706), personalization 
system 116 and RFID reader 104 may engage in a mutual 
authentication process using the existing security keys al- 
ready stored on RFID reader 104 (step 710). If authentica- 
tion is unsuccessful (step 712), personalization system 
116 may abort the personalization process (step 714). 

[0103] Where personalization system 116 and RFID reader 104 

successfully mutually authenticate, personalization system 
116 may update RFID reader 104 security keys (step 716). 



Updating the security l<eys may tal<e place at any time as 
determined by a system 100 manager. Tlie updating may 
take place as part of a routine maintenance or merely to 
install current security key data. The updating may be 
performed by downloading firmware into RFID reader 104 
(step 718). In the event that personalization system 116 
determines in step 706 that RFID reader 104 is undergo- 
ing an initial personalization, the firmware may be loaded 
into RFID reader 104 for the first time. In this context, 
"firmware" may include any file which enables the RFID 
reader 102 to operate under system 100 guidelines. For 
example, such guidelines may be directed toward the op- 
eration of RFID reader protocol/sequence controller 314. 
[0104] Personalization system 116 may then determine if the 

personalization keys (e.g., security keys, decryption keys, 
RFID identifier) need to be updated or if RFID reader 104 
needs to have an initial installation of the personalization 
keys (step 720). If so, then personalization system 116 
may download the personalization keys as appropriate 
(step 722). 

[0105] Personalization system 116 may then check RFID reader 
104 to determine if fob 102 identifiers and corresponding 
security keys should be updated or initially loaded (step 



724). If no updating is necessary personalization system 
116 may end the personalization procedure (step 732). 
Contrarily, if personalization system 116 determines that 
fob 102 identifiers and corresponding keys need to be 
updated or installed, personalization system 116 may 
download the information onto RFID reader 104 (step 
726). The information (e.g., fob security keys and identi- 
fiers) may be downloaded in an encrypted format and 
RFID reader 104 may store the information in the RFID 
reader database 310 as appropriate (step 728). Personal- 
ization system 116 may then create or update a status log 
cataloging for later use and analysis by personalization 
system 116 user (step 730). Upon updating the status log, 
the personalization process may be terminated (step 732). 

[0106] It should be noted that, in some instances it may be nec- 
essary to repersonalize the RFID reader in similar manner 
as described above. In that instance, the personalization 
process described in FIGS. 7A and 7B may be repeated. 

[0107] FiG_ 8 illustrates an exemplary flow diagram for the oper- 
ation of system lOOA. The operation may be understood 
with reference to FIG. lA, which depicts the elements of 
system lOOA which may be used in an exemplary transac- 
tion. The process is initiated when a customer desires to 



present fob 102 for payment (step 802). Upon presenta- 
tion of fob 102, the merchant initiates the RF payment 
procedure via an RFID reader 104 (step 804). In particular, 
the RFID reader sends out an interrogation signal to scan 
for the presence of fob 102 (step 806). The RF signal may 
be provided via the RFID reader antenna 106 or optionally 
via external antenna 108. The customer then may present 
fob 102 for payment (step 808) and fob 102 is activated 
by the RF interrogation signal provided. 

[0108] Fob 102 and RFID reader 104 may then engage in mutual 
authentication (step 810). Where the mutual authentica- 
tion is unsuccessful, an error message may be provided to 
the customer via the RFID optical and/or audible indicator 
(step 814) and the transaction may be aborted (step 816). 
Where the mutual authentication is successful (step 812), 
RFID reader 104 may provide the customer with an appro- 
priate optical and/or audible message (e.g., "transaction 
processing" or "wait") (step 818). The fob protocol/se- 
quence controller 208 may then retrieve from database 
214 an encrypted fob account number and provide the 
encrypted account number to RFID reader 104 (step 820). 

[0109] RFID reader 104 may then decrypt the account number 
and convert the account number into magnetic stripe 



(ISO/IEC 7813) format (step 822) and provide the unen- 
crypted account number to merchant system 130 (step 
828). In particular, the account number may be provided 
to POS 110 device for transmission to merchant network 
112 for processing. Exemplary processing methods ac- 
cording to the present invention are discussed with re- 
spect to FIGS. 10-13, shown below. Upon processing, POS 
device 110 may then send an optical and/or audible 
transaction status message to RFID reader 104 (step 830) 
for communication to the customer (step 832). 
10] The methods for processing the transactions may include 
one of several formats as required by the fob issuer. For 
example, one processing method may include processing 
the transaction under a preloaded fob format wherein a 
payment value (e.g., monetary value, reward points value, 
barter points value, etc.) may be preloaded into a 
preloaded value account or data file prior to permitting 
usage of the fob. In this way, the user may be permitted 
to set aside a payment amount for transactions for goods 
and services using the fob. During processing of the 
transaction, approval of the transaction may involve com- 
paring the transaction amount to the amount stored (or 
remaining) in the preloaded value data file. Comparison 



may be made by a preloaded value processing system 
wherein the preloaded value processing system may com- 
pare the transaction amount to be processed to the 
preload value data file. Where the transaction amount ex- 
ceeds the amount stored in the preloaded value account, 
the preloaded value processing system may deny autho- 
rization for completion of the transaction, request that the 
user increase the value in the data file, request another 
form of payment to satisfy all or a portion of the transac- 
tion amount, and/or any other means to satisfy the asso- 
ciated financial institution of payment. Where the transac- 
tion amount does not exceed the amount stored in the 
preloaded value data file account, the preloaded value 
processing system may provide for authorization of the 
transaction. 

^] An exemplary preloaded value processing system 1000 is 
shown with respect to FIG. 10. Preloaded value processing 
system 1000 may include fob 102 including transponder 
114, which is in communication with a merchant system 
130 via RFID reader 104 or computer interface 134 as is 
described with respect to FIG. lA. The merchant system 
may be in communication with an issuer system 1010, 
where issuer system 1010 may be maintained by any en- 



tity (e.g., non-financial or financial institution, American 
Express®, Visa® and/or MasterCard®, etc.) which permits 
fob 102 user to store a preload value amount in a 
preloaded value account (e.g., data file) maintained on an 
issuer database 1012 of similar construction as database 
212. Issuer system 1010 may further include one or more 
process servers for processing a fob transaction. As 
shown, POS device 110 (included in merchant system 130) 
may be in communication with an issuer account server 
(IAS) 1014 for receiving the fob account information from 
POS device 110. IAS 1014 may be in further communica- 
tion with a preloaded value authorization server (PLAS) 
1016 for processing transactions involving a preloaded 
value fob. PLAS 1016 may be in further communication 
with issuer database 1012 for retrieving funds from the 
preloaded value data file (not shown) which are used for 
satisfying the preloaded fob or merchant transaction re- 
quest. In this instance, the preloaded value data file may 
be included on database 1012 as, for example, one or 
more sub-files. 
12] As used herein, the term "issuer" or "account provider" 
may refer to any entity facilitating payment of a transac- 
tion using a fob, and may include systems permitting pay- 



ment using at least one of a preloaded and non-preloaded 
fob. Typical issuers may be, for example, American Ex- 
press®, MasterCard®, Visa, Discover®, and the like. In the 
preloaded value processing context, an exchange value 
(e.g., money, rewards points, barter points, etc.) may be 
stored in a preloaded value data file for use in completing 
a requested transaction. In one embodiment, the ex- 
change value is not be stored on the fob itself. Further, 
the preloaded value data file may be debited the amount 
of the transaction, so the preloaded value account may be 
replenished. As described more fully below, the preloaded 
value system platform may be used to complete "direct 
link" transactions. In which case, the preloaded value ac- 
count may function as a place holder and may store a zero 
value. 

[0113] The preloaded value data file may be any conventional 

data file configuration for storing a value (e.g., monetary, 
rewards points, barter points, etc.) which may be ex- 
changed for goods or services. In that regard, the 
preloaded value data file may have any configuration as 
determined or desired by the issuer system 1010. 

[0114] In exemplary operation, fob identifying information (e.g., 
account number or fob marker) may be provided to POS 



device 110 in similar manner as was discussed witli re- 
spect to FIG. lA. That is, fob 102 may be presented to 
merchant system 130 via RFID reader 104 or a computer 
interface 134, which may provide the fob identifying in- 
formation in Track 1 or Track 2 format, or any format rec- 
ognizable by POS device 110 and/or issuer system 1010. 
POS device 110 included in merchant system 130 may re- 
ceive fob 102 identifying information and provide fob 102 
identifying information along with the transaction identi- 
fying information (e.g., amount, quantity, merchant iden- 
tification, etc.) to issuer system 1010 for authorization. 
Merchant system 130 may additionally include a merchant 
system marker or identifier for indicating a merchant sys- 
tem identity. Merchant system 130 may combine fob 102 
identifying information, the merchant identifying informa- 
tion, and/or the transaction identifying information, into a 
merchant transaction request for providing to the issuer 
system 1010. 

^5] IAS 1014 may receive the transaction and fob identifying 
information (or merchant transaction request) and suitably 
recognize that the transaction is being requested relative 
to a preloaded value account associated with a preloaded 
fob. That is, IAS 1014 may recognize that the user has 



presented a preloaded fob 102 for payment. Recognition 
of fob 102 as a preloaded fob may mean that the fob 
identifying information includes a marker or identifier in- 
dicating that the fob is associated with a preloaded value 
data file. Upon recognition of the marker, IAS 1014 may 
forward transaction and fob identifying information to 
PLAS 1016 for processing. PLAS 1016 may compare the 
transaction amount to the value stored or remaining in the 
preloaded value to determine if authorization should be 
granted or denied. Where the transaction amount exceeds 
the value stored in the preloaded value data file, PLAS 
1016 may forward a transaction denied message to IAS 
1014 for providing to the merchant system 130, or the 
PLAS may facilitate a request that the user increase the 
value in the data file, request another form of payment to 
satisfy all or a portion of the transaction amount, and/or 
any other means to satisfy the associated financial institu- 
tion of current or future payment. Alternatively, where the 
transaction amount is less than or equal to the value 
stored in the preload value data file PLAS 1016 may 
deduct from the preloaded value data file the necessary 
amount for satisfaction of the transaction. 
^6] As noted above, in one exemplary embodiment of the 



present invention, PLAS 1016 may provide a transaction 
denied message to IAS 1014 for various financial security 
reasons, such as where the amount stored in the 
preloaded value account is less than required for satisfy- 
ing the merchant or fob transaction request. In this in- 
stance, where the preloaded value falls below a predeter- 
mined minimum level (e.g., minimum depletion level), it 
may be necessary for the fob user to reload the preloaded 
value data file. Reloading of the preloaded value account 
may take place manually (e.g., by the fob user telephoni- 
cally or online) or may take place automatically when the 
value stored in the preloaded value data file is depleted to 
a predefined level. Where the reloading is done automati- 
cally, reloading may occur under rules established by the 
fob issuer or owner. For example, reloading may occur at 
preselected time intervals, when the value stored is below 
a predetermined amount, until a maximum number of 
reloads in a predetermined time period has occurred or 
until a maximum reload amount is reached in a predeter- 
mined time period. 
"1 7] In another exemplary operation, processing system 1000 
may be operated offline. For example, merchant system 
130 may be offline with respect to issuer system 1010. 



That is, transactions may be approved at merchant system 
130, prior to the transaction identifying information being 
transferred to the issuer system. Instead, merchant sys- 
tem 130 may be provided an approval protocol for use in 
evaluating the merchant transaction request. For example, 
the approval protocol may provide for transaction ap- 
proval where the transaction is below a certain amount, 
includes a particular merchant or goods or service, or is 
requested from a particular location or the like. Once the 
offline transaction is completed, the merchant may seek 
satisfaction of the transaction at a later time-period by 
submitting the transaction to the issuer individually, in 
batch, or under any submission processing determined by 
the merchant. 

18] For offline transactions, fob 102 may include a counter 
(not shown) which may track the number of offline trans- 
actions. Once a predetermined number of transactions are 
attempted, the counter may be used to facilitate disen- 
abling fob 102 usage. At which point fob 102 user may be 
required to perform an online transaction whereby the 
counter may be reset, again permitting offline usage of 
the fob. As can be understood, requiring online usage fol- 
lowing a predetermined number of offline usages may 



function as an additional security measure. 

[0119] FIGS. IIA and IIB depict exemplary preloading and 

reloading processes which may be performed in accor- 
dance with the present invention. The preloading and 
reloading processes may be preformed using one or more 
servers (e.g., PLAS 1016) in communication with a funding 
source 1104. Although the processes are demonstrated 
using a PLAS 1016, it is contemplated that any server 
configured for establishing and managing data files may 
be used. However, to facilitate further understanding of 
the invention, the preloading and reloading aspects of the 
invention are described with reference to PLAS 1016. 

[0120] PLAS 1016 may be used to establish on the server or on a 
database (e.g., database 1012) a preloaded value account 
(e,g, data file) (1106). The preload value account may be 
funded or maintained by a fob issuer/account provider 
which may establish a credit, charge, debit, rewards value 
account, loyalty account, or the like, in connection with a 
charge or credit card (e.g.. Visa, MasterCard, American 
Express, Discover, etc.), debit or direct debit authorization 
(DDA) system. 

[0121] The preloaded value account may be established to at 

least a predetermined minimum preload amount or value 



(e.g., minimum preload level) as determined by the ac- 
count provider and/or the fob user or owner. In this con- 
text, the predetermined minimum value (e.g., minimum 
preload value) required to establish the preloaded value 
account may vary with respect to a particular fob user. 
The preloaded value account may be loaded (e.g., 
preloaded or reloaded) from funds received from one of a 
funding source 1104 (American Express, Visa, Master- 
Card, Discover, fuel cards, or the like). Further, the 
preloaded value account may be loaded with value re- 
ceived from loyalty or rewards points provider. To facili- 
tate the understanding of the invention, the loyalty or re- 
wards point provider may be referred to herein as a fund- 
ing source. Thus, PLAS 1016 may communicate with the 
funding source 1104 to obtain funds or value for loading 
and/or reloading the preloaded value account (1108). 
[0122] FIG. IIB shows an exemplary reloading process in accor- 
dance with the invention. During operation, a consumer 
may present to merchant system 130 the prepaid fob 102 
for purchasing goods or services (1110). The preloaded 
value account is then depleted the value amount paid to 
merchant system 130. The process for purchasing goods 
may be repeated until the value stored in the preloaded 



value account equals or is less than a minimum level bal- 
ance (e.g., minimum depletion level). The minimum de- 
pletion level may be predetermined by the fob user or fob 
issuer, and may be the minimum value permitted to be 
stored in the preloaded value account before the file is to 
be reloaded. 

[0123] Once the preloaded value data is depleted such that the 
minimum depletion level is reached, PLAS 1016 may trig- 
ger an automatic reload to reload the preloaded value ac- 
count from funds retrieved from the funding source 1104 
(1112). The amount of funds retrieved may be sufficient 
for loading the preloaded value account to the minimum 
amount described above or to some other predetermined 
reload value. In one exemplary embodiment, PLAS 1016 
may trigger automatic reloading where a predetermined 
minimum depletion level (e.g., "minimum level balance") is 
reached. That is, the preloaded value account may not be 
entirely depleted to zero value before automatic reloading 
occurs. In this instance, PLAS 1016 may charge the fund- 
ing necessary for automatic reloading against the avail- 
able funds at funding source 1104. In another exemplary 
embodiment, the automatic reloading may occur where 
the transaction exceeds the amount stored in or remain- 



ing in the preloaded value account. In this way, the 
preloaded value account may be restored to an amount 
necessary for completion of the transaction. For example, 
where automatic reloading restores the preloaded value 
account to a value suitable for transaction completion, the 
preloaded value account may be automatically reloaded 
prior to processing the transaction. 

[0124] In another exemplary embodiment, automatic reloading 
may occur based on different user or issuer automatic 
reload criteria. Other automatic reload criteria may in- 
clude, but are not limited to, reloading until a defined 
maximum load amount in a defined time period is 
reached, reloading at a selected reoccurring time interval 
(e.g., once a month), reloading as permitted until a de- 
fined maximum number of reloads in a specified time pe- 
riod is reached, or reloading until a defined maximum 
reload amount is reached in a specified time period. In 
some instances, reloading may be accomplished manually, 
such as, for example, when the fob user contacts the is- 
suer telephonically or via user interface to provide a spec- 
ified funding criteria and funding source for use in 
reloading the preloaded value account. 

[0125] In yet another exemplary embodiment, the preloaded 



value transaction processing system may permit approval 
of a transaction where the transaction value exceeds the 
preloaded value amount stored in the preloaded value ac- 
count. That is, the preloaded fob may be used for pur- 
chases exceeding the preloaded value amount provided 
that the charge submitted by the merchant is less than or 
equal to the maximum reload amount permitted plus the 
amount stored on the card at the time the charge is sub- 
mitted. 

[0126] In another exemplary embodiment, the preloaded value 
system may approve transactions based on a particular 
merchant's transaction processing protocol. Where the is- 
suer has reviewed and/or approved a merchant's transac- 
tion processing method, the system may take the method 
in consideration in determining whether to approve a 
merchant's transaction request. For example, a merchant's 
transaction processing method may include the merchant 
submitting transaction requests which exceed the 
preloaded value amount, but the actual charge may be 
less than or equal to the preloaded value amount. Under 
this transaction processing method a merchant, such as, 
for example, a gasoline merchant, may seek pre-approval 
of an anticipated gasoline fueling amount. Neither the 



consumer nor the merchant may know the exact final 
value of the purchase, especially, for example, where the 
consumer decides to fill his automobile gas tank or pur- 
chase non-fuel items. Thus, the merchant may submit a 
transaction request which may be higher than the final 
amount of the transaction. The merchant may submit the 
transaction request in real-time or at a later time period 
in a similar manner as is described above with respect to 
offline transaction request processing. In either on line or 
off line processing, the preloaded value transaction pro- 
cessing system may still be configured to approve the 
transaction request. The processing system may recog- 
nize that a transaction came from a particular merchant 
and institute a predetermined approval protocol correla- 
tive to that merchant, since the approval protocol may in- 
clude information that the merchant is sending a transac- 
tion request exceeding the actual charge. 
[0127] The transaction processing system may use any one of the 
acceptable techniques for identifying merchants, such as 
recognition of the merchant ID, or a marker appended to 
the transaction, or the like. The processing system may 
correlate the merchant ID with a merchant protocol for re- 
questing a transaction approval of an amount greater than 



the preloaded value (or reload value), and approve the 
merchant request accordingly. 

[0128] In accordance with an alternate exemplary embodiment of 
a preloaded value processing system 1000, upon receiv- 
ing the transaction request from the IAS 1014, PLAS 1016 
may evaluate the transaction request based upon several 
risk criteria established by the issuer for either online or 
offline transactions. If all the criteria are successfully met, 
then PLAS 1016 may send authorization of the transaction 
(e.g., "transaction granted") to IAS 1014 for providing to 
merchant system 130. Simultaneous with or subsequent 
to, providing the transaction authorization to the IAS 
1014, PLAS 1016 may seek satisfaction of the transaction 
from the fob value account maintained on the account 
provider database 1012. The transaction request may be 
provided to IAS 1014 for processing. That is, IAS 1014 
may seek to deduct the transaction value from the balance 
of the amount stored in the preloaded value account. 

[0129] FIG, 12 depicts an exemplary embodiment of another 

transaction processing system ("direct link" system) 1200 
in accordance with the present invention. More particu- 
larly, FIG. 12 depicts a direct link system 1200 which may 
be used to process a merchant transaction request. In this 



context, a direct link system may be any system whicli fa- 
cilitates satisfaction of a transaction request using a fob 
or other presentable medium (credit card, charge card, 
debit card, or the like) directly linked to an account which 
stores an exchange value (e.g., money, credit or charge, 
or rewards points, etc.). In this instance, the preloaded 
value account may not be preloaded as described above. 
Further, the preloaded value account may be linked to a 
contact financial product such as a credit, debit, and/or 
DDA card, and the like, which may be presented for pay- 
ment of goods and services. In this regard, the fob (here 
called "direct link fob") and the card are associated with 
the same funding source and the user or merchant may 
seek satisfaction of a transaction from the funding source 
independent of whether the direct link fob or card is used. 
In the exemplary direct link system 1200, the direct link 
fob 102 user may not establish a preloaded value account 
with value. Instead, the preloaded value account may per- 
petually store a zero value or fob 102 may be associated 
with a fob transaction account which may be used to pro- 
vide payment to the merchant for goods and services 
where the account may be a credit, debit, loyalty account 
or the like. 



[0130] In accordance with an exemplary embodiment of tlie in- 
vention, a transaction request associated with a direct linic 
fob 102 may be processed using the preloaded value 
transaction system processing described above. However, 
as noted, in this instance the preloaded value account is 
used as a place holder storing a zero value. A transaction 
account containing a transaction account value which is 
associated with the direct link fob is treated as the fund- 
ing source for satisfying direct link transactions. In this 
instance, the transaction may be satisfied according to a 
fob user or issuer predefined protocol or criteria. 

[0131] As shown, merchant system 130 may be in communica- 
tion with an issuer system 1010 for receiving a merchant 
transaction request. More particularly, POS device 110 
may be in communication with an issuer server, such as, 
for example, an issuer account server (IAS) 1014 for re- 
ceiving the merchant and/or transaction identifying infor- 
mation. IAS 1014 may be in further communication with a 
PLAS 1016 for processing the merchant transaction re- 
quest. In some instances PLAS 1016 may be in further 
communication with a second IAS 1202, although a sec- 
ond IAS 1202 may not be required where one or more of 
the existing servers may perform the functions of IAS 



1202 described below. However, the IAS 1202 is included 
herein to simplify the understanding the operation of this 
exemplary embodiment. 
[0132] In exemplary operation of system 1200, the direct link fob 
identifying information (e.g., fob identifier or account 
number) may be provided to POS device 110 in similar 
manner as was discussed with respect to FIG. lA. That is, 
the direct link fob 102 may be presented to merchant sys- 
tem 130 via RFID reader 104 or computer interface 134, 
which may provide the direct link fob 102 identifying in- 
formation in Track 1 or Track 2 format. POS device 110 
included in merchant system 130 may receive the direct 
link fob 102 identifying information and provide the direct 
link fob 102 identifying information along with the trans- 
action identifying information (e.g., amount, quantity, 
merchant identification, etc.) to issuer system 1010 for 
authorization. 

[0133] IAS 1014 may receive the transaction and fob identifying 
information and recognize that the transaction as being 
requested relative to a direct link fob 102. Recognition of 
the direct link fob 102 in this instance may mean that the 
direct link fob 102 identifying information includes a 
marker or identifier indicating that the fob is associated 



with a zero value preloaded value account. Upon recogni- 
tion of the marker, IAS 1014 may forward the transaction 
and fob identifying information to PLAS 1016 for process- 
ing. 

[0134] In similar manner as was described with respect to the 

operation of the preloaded value processing system of FIG 
10, PLAS 1016 may evaluate the transaction request based 
upon several risk criteria established by the issuer. Exem- 
plary risk criteria may include, but are not limited to, con- 
sideration of transaction amount limits for a specified 
time period, fob user usage history, fund or reserve limits, 
pre-determined re-funding rules, user defined limits, or 
any similar evaluative criteria. If all the criteria are suc- 
cessfully met, then PLAS 1016 may send authorization of 
the transaction (e.g., "transaction granted") to IAS 1014 
for providing to merchant system 130. The transaction 
authorization may be provided to merchant system 130 
based on evaluation of the risk criteria and not upon the 
value present in preloaded value account or direct link 
transaction account storing value relative to the direct link 
fob. 

[0135] After providing the transaction authorization to the IAS 
1014, PLAS 1016 may seek authorization of the transac- 



tion against the direct linic fob account (e.g., transaction 
account) which is maintained on issuer database 1012, 
and which is funded by value received from funding 
source 1104. The authorization request may be provided 
to IAS 1202 for approval which may retrieve the necessary 
value from the direct link fob account. For example, where 
the direct link fob account is a charge or credit account, 
PLAS 1016 may request authorization from the second IAS 
1202 and IAS 1202 may assess the transaction amount 
against the direct link fob account on database 1012. IAS 
1202 may seek to record the amount of the transaction in 
the direct link fob usage history data file for payment at 
the end of a billing cycle (e.g., charge account), or the 
amount may be recorded on the fob direct link fob usage 
data file for payment at a date later than the end of the 
billing cycle (e.g., credit account). 
[0136] In an alternative operation PLAS 1016 may assess the 
transaction amount against the direct link fob account, 
without use of a second IAS 1202. Whether the transaction 
is processed using a second IAS 1202, it is to be under- 
stood that value may not be immediately transferred to 
the merchant system from the direct link fob account for 
satisfying the transaction. Instead, the direct link fob is- 



suer may guarantee satisfaction of tlie merchant transac- 
tion by, for example, request until a certain value is re- 
trieved from the direct link fob account at the end of the 
billing cycle or later. That is, PLAS 1016 may provide au- 
thorization of the transaction, but may not retrieve the 
necessary value for satisfying the transaction until after 
the merchant provides a request for settlement to the is- 
suer system. 

[0137] In yet another exemplary transaction processing system 
1300 depicted in FIG. 13, merchant system 130 may pro- 
vide a batch file containing multiple fob transaction re- 
quests to be processed to a process server 1302 where 
the multiple fob transactions may include both preloaded 
value and direct link transaction request. The system 
1300 may include a processserver 1302 which distin- 
guished between preloaded value and direct link transac- 
tion requests. That is, process server 1302 may be used 
for separating the fob transactions which are associated 
with a preloaded fob account and those that are not asso- 
ciated with a preloaded fob account, as discussed more 
fully below. Process server 1302 may further be in com- 
munication with IAS 1014 for seeking settlement of the 
transaction. IAS 1014 may process the transaction request 



in accordance with tlie direct linl< transaction process or 
the preloaded value transaction platform described above. 
[0138] In exemplary operation of system 1300, process server 
1302 may receive the settlement file and identify the files 
according to the nature of the transaction request. For ex- 
ample, process server 1302 may place markers on the 
files received and create sub-files of transaction requests 
relative to the type of fob used in the transaction (e.g., 
preloaded fob, and direct link fob associated with a 
charge or credit account). The process server may create 
the sub-files relative to the file markers. Process server 
1302 may create a first fob transaction file for merchant 
payables and a second fob transaction file for accounts 
receivable to be forwarded to IAS 1014 for processing. 
Where the sub-file includes merchant payable, process 
server 1302 may provide funds to the merchant for pay- 
ment of the transaction, where the funds provided may be 
equivalent to the transaction amount minus discount rev- 
enues. The funds may be retrieved from the funding 
source for providing to the merchant. Alternatively, pro- 
cess server 1302 may create a second fob transaction file 
for accounts receivable payments and forwarded the sec- 
ond fob transaction file to IAS 1014. IAS 1014 may then 



process the transaction request according to tlie pro- 
cesses described in FIGS. 10 and 12. Tliat is, IAS 1014 
may distinguish the preloaded fob transaction requests 
from those associated with the direct link fob and process 
the transactions accordingly. 
[0139] Considering the operation of the various transaction pro- 
cessing systems described above, it can be seen that the 
transaction processing systems described may distinguish 
when a preloaded fob is used, when a card associated 
with a fob is used, or when an account associated with a 
preloaded fob is reloaded. In that regard, the present in- 
vention may be used to reward points depending on the 
nature of the fob usage. The points (e.g., loyalty points) 
may be stored in a points or rewards account maintained 
on the issuer database (e.g., database 1012). The rewards 
points may then later be redeemed from the rewards ac- 
count for exchange for goods and services as desired by 
the fob user. For more information on loyalty systems and 
transaction systems, see, for example, U.S. Patent Appli- 
cation Serial No.: 09/836,213, filed on April 17, 2001, by 
inventors Voltmer, et al., and entitled "System And Method 
For Networked Loyalty Program"; U.S. Continuation- 
In-Part Patent Application Serial No. 10/027,984, filed on 



December 20, 2001, by inventors Ariff, et al., and entitled 
"System And l\/lethod For Networl<ed Loyalty Program"; U.S. 
Continuation-ln-Part Patent Application Serial No. 
10/010,947, filed on November 6, 2001, by inventors 
Haines, et al., and entitled "System And Method For Net- 
worked Loyalty Program"; the Shop AMEX™ system as dis- 
closed in Serial No. 60/230,190, filed September 5, 2000; 
the MR as Currency™ and Loyalty Rewards Systems dis- 
closed in Serial No. 60/197,296, filed on April 14, 2000, 
Serial No. 60/200,492, filed April 28, 2000, and Serial No. 
60/201,114, filed May 2, 2000; a stored value card as 
disclosed in Serial No. 09/241,188, filed on February 1, 
1999; a system for facilitating transactions using sec- 
ondary transaction numbers disclosed in Serial No. 
09/800,461, filed on March 7, 2001, and also in related 
provisional applications Serial No. 60/187,620, filed 
March 7, 2000, Serial No. 60/200,625, filed April 28, 
2000, and Serial No. 60/213,323, filed May 22, 2000, all 
of which are herein incorporated by reference. Other ex- 
amples of online membership reward systems are dis- 
closed in Netcentives, U.S. Patent No. 5,774,870, issued 
on June 30, 1998, and U.S. Patent No. 6,009,412, issued 
on December 29, 1999, both of which are hereby incorpo- 



rated by reference. 

[0140] As noted, in one instance, points may be provided wlien 
the fob is used in addition to wlien the card associated 
with the fob is used. For example, IAS 1014 may recog- 
nize that a fob is being used and award points (e.g., loy- 
alty points) to the rewards account assigned to the fob 
user or associated with the fob. The loyalty points may be 
awarded based on any criteria as determined by the fob 
issuer. Exemplary rewarding criteria may include reward- 
ing points for, for example, frequency of fob usage, 
amount of individual purchase using the fob, the total 
amount of purchases in a given time period, location of 
merchant, type of merchant, or any such criteria for in- 
centing fob usage. 

[0141] Where the fob is associated with a preloaded value ac- 
count such as that described with respect to FIG. 10, 
points may be awarded for account reloading. That is, IAS 
1014 may place award points in the rewards account rela- 
tive to the amount loaded or reloaded as required. Further 
IAS 1014 may place reward points in the rewards account 
relative to usage of the fob at a particular merchant or for 
a particular transaction. 

[0142] It should be noted that the transaction account associated 



with fob 102 may include a usage restriction, sucli as, for 
example, a per purchase spending limit, a time of day use, 
a day of week use, certain merchant use and/or the like, 
wherein an additional verification is required when using 
the fob outside of the restriction. The restrictions may be 
personally assigned by fob 102 user, or the account 
provider. For example, in one exemplary embodiment, the 
account may be established such that purchases above $X 
(i.e., the spending limit) must be verified by the customer. 
Such verification may be provided using a suitable per- 
sonal identification number (PIN) which may be recog- 
nized by fob 102 or a payment authorization center (not 
shown) as being unique to fob 102 holder (e.g., customer) 
and the correlative fob 102 transaction account number. 
Where the requested purchase is above the established 
per purchase spending limit, the customer may be re- 
quired to provide, for example, a PIN, biometric sample 
and/or similar secondary verification to complete the 
transaction. That is, for example, fob 102 may enter the 
unique PIN in a conventional keypad at merchant system 
130 or RFID reader 104. The PIN may be provided to the 
authorization center for comparison with a correlative PIN 
stored on the issuer system. Alternatively, the PIN may be 



provided to fob 102 via RFID reader 104. Fob 102 may 
verify tlie PIN by comparing tlie PIN to a correlative PIN 
stored on, for example, secure memory 212. 
[0143] Where a verification PIN is used as secondary verification 
the verification PIN may be checked for accuracy against a 
corroborating PIN which correlates to fob 102 transaction 
account number. The corroborating PIN may be stored lo- 
cally (e.g., on fob 102), or may be stored on a database 
(1012) at the payment authorization center. The payment 
authorization center database may be any database 1012 
maintained and operated by fob 102 transaction account 
provider. 

[0144] The verification PIN may be provided to POS device 110 

using a conventional merchant (e.g., POS) PIN key pad 118 
in communication with POS device 110 as shown in FIG. 
lA, or a RFID keypad in communication with RFID reader 
104. PIN keypad may be in communication with POS de- 
vice 110 (or alternatively, RFID reader 104) using any con- 
ventional data link described above. Upon receiving the 
verification PIN, RFID reader 104 may seek to match the 
PIN to the corroborating PIN stored on RFID reader 104 at 
database 310 or 320. Alternatively, the verification PIN 
may be provided to a payment authorization center to de- 



termine whether the PIN matches the PIN stored on the 
payment authorization center database which correlates 
to fob 102 account. If a match is made, the purchase may 
no longer be restricted, and the transaction may be al- 
lowed to be completed. 

[0^45] In an alternate embodiment, verification of purchases ex- 
ceeding the established spending limit may involve bio- 
metrics circuitry included in fob 102. FIG. 9 is a schematic 
block diagram of an exemplary fob 102 wherein fob 102 
includes a biometric security system 902. Biometric secu- 
rity system 902 may include a biometric sensor 904 for 
sensing the fingerprint of fob 102 user. Biometric sensor 
904 may be in communication with a sensor interface/ 
driver 906 for receiving the sensor fingerprint and activat- 
ing the operation of fob 102. In communication with bio- 
metric sensor 904 and sensor interface 906 may be a bat- 
tery 903 for providing the necessary power for operation 
of the biometric security system components. 

[0146] In one exemplary application of fob 102 including bio- 
metric security system 902, the customer may place his 
finger on the biometric sensor to initiate the mutual au- 
thentication process between fob 102 and RFID reader 
104, or to provide secondary verification of the user's 



identity. The sensor fingerprint may be digitized and 
compared against a digitized fingerprint stored in a 
database (e.g., security database 212) included on fob 
102. Sucli comparison step may be controlled by proto- 
col/sequence controller 208 and may be validated by au- 
thentication circuit 210. Where such verification is made, 
the mutual authentication between fob 102 and RFID 
reader 104 may begin, and the transaction may proceed 
accordingly. Alternatively, the comparison may be made 
with a digitized fingerprint stored on a database main- 
tained by fob 102 transaction account provider system 
(not shown). The digitized fingerprint may be verified in 
much the same way as is described above with respect to 
the PIN. 

[0147] In one exemplary application of fob 102 including bio- 
metric security system 902, system 902 may be used to 
authorize a purchase exceeding the established per pur- 
chase spending limit. In this case, where the customer's 
intended purchase exceeds the spending limit, the cus- 
tomer may be asked to provide assurance that the pur- 
chase is authorized. Accordingly, the customer may pro- 
vide such verification by placing his finger over biometric 
sensor 904. Biometric sensor 904 may then digitize the 



fingerprint and provide tlie digitized fingerprint for verifi- 
cation as described above. Once verified, fob 102 may 
provide a transaction authorized signal to RF transponder 
202 (or alternatively to transponder 220) for forwarding to 
RFID reader 104. RFID reader 104 may then provide the 
transaction authorized signal to POS device 110 in similar 
manner as is done with conventional PIN driven systems 
and POS device 110 may process the transaction under 
the merchant's business as usual standard. 

[0148] Additional methods and systems for biometric security for 
system 100 will be discussed further herein. 

[0149] In accordance with another exemplary embodiment of the 
invention, the fob user is provided limited access to a fob 
user data file maintained on an issuer system for manag- 
ing the fob usage and fob user information. User may 
have access over the phone, online, or offline. The fob 
user may access the fob user data file to change, for ex- 
ample, demographic information (e.g., fob user address, 
phone number, email address, or the like), the funding 
source (e.g., credit account, charge account, rewards ac- 
count, barter account, etc.) associated with the fob, view 
the transaction history, etc. In addition, the fob user may 
be permitted to load or reload the account or alter auto- 



matic reload parameters (e.g., amount to reload, period 
for reloading, etc.). Where more than one fob 102 is cor- 
related to a transaction account, the user may be provided 
similar access to the data files corresponding to the addi- 
tional fobs. 

[0150] vvith reference to FIG. lA, the fob user may connect fob 
102 to computer interface 134 via the USB interface 132. 
The fob user may then use computer interface 134 to ac- 
cess the fob user data file via network 136. In particular, 
network 136 may be in communication with an issuer sys- 
tem (e.g., system 1010 of FIG. 10) and may be provided 
limited access to an issuer server (e.g., server 1014) for 
managing the fob. Issuer server 1014 may be in commu- 
nication with an issuer system database (e.g., 1012) which 
stores the information to be managed relative to the user 
fob user data file. The changes made to the fob user data 
file by the fob user may be made in real-time, after a brief 
delay, or after an extended delay. In one instance, 
changes may be stored in a batch changes file on the is- 
suer database for later batch processing. 

[0151] In another exemplary embodiment of the present inven- 
tion, system 100 may be configured with one or more 
biometric scanners, processors and/or systems. A bio- 



metric system may include one or more technologies, or 
any portion thereof, such as, for example, recognition of a 
biometric. As used herein, a biometric may include a 
user's voice, fingerprint, facial, ear, signature, vascular 
patterns, DNA sampling, hand geometry, sound, olfactory, 
keystroke/typing, iris, retinal or any other biometric relat- 
ing to recognition based upon any body part, function, 
system, attribute and/or other characteristic, or any por- 
tion thereof. Certain of these technologies will be de- 
scribed in greater detail herein. Moreover, while some of 
the examples discussed herein may include a particular 
biometric system or sample, the invention contemplates 
any of the biometrics discussed herein in any of the em- 
bodiments. 

[0152] The biometric system may be configured as a security 

system and may include a registration procedure in which 
a user of transaction instrument (e.g., fob 102) proffers a 
sample of his fingerprints, DNA, retinal scan, voice, and/ 
or other biometric sample to an authorized sample re- 
ceiver (ASR). An ASR may include a local database, a re- 
mote database, a portable storage device, a host system, 
an issuer system, a merchant system, a fob issuer system, 
an employer, a financial institution, a non-financial insti- 



tution, a loyalty point provider, a company, the military, 
the government, a school, a travel entity, a transportation 
authority, a security company, and/or any other system or 
entity that is authorized to receive and store biometric 
samples and associate the samples with specific biometric 
databases and/or transaction instruments (e.g., fobs 102). 
As used herein, a user of a fob, fob user, or any similar 
phrase may include the person or device holding or in 
possession of the fob, or it may include any person or de- 
vice that accompanies or authorizes the fob owner to use 
the fob. 

[0153] FIG. 14 illustrates an exemplary registration procedure in 
accordance with the present invention. In one embodi- 
ment, a fob user may contact an ASR to submit one or 
more biometric samples to an ASR (step 1401). The fob 
user may contact the ASR and submit a sample in person, 
through a computer and/or Internet, through software 
and/or hardware, through a third-party biometric autho- 
rization entity, through a kiosk and/or biometric registra- 
tion terminal, and/or by any other direct or indirect 
means, communication device or interface for a person to 
contact an ASR. 

[0154] A fob user may then proffer a biometric sample to the ASR 



(step 1403). As used herein, a biometric sample may be 
any one or more of the biometric samples or technologies, 
or portion thereof, described herein or known in the art. 
By proffering one or more biometric samples, a biometric 
may be scanned by at least one of a retinal scan, iris scan, 
fingerprint scan, hand print scan, hand geometry scan, 
voice print scan, vascular scan, facial and/or ear scan, 
signature scan, keystroke scan, olfactory scan, auditory 
emissions scan, DNA scan, and/or any other type of scan 
to obtain a biometric sample. Upon scanning the sample, 
the system may submit the scanned sample to the ASR in 
portions during the scan, upon completing the scan or in 
batch mode after a certain time period. The scanned sam- 
ple may include a hardcopy (e.g., photograph), digital 
representation, an analog version or any other configura- 
tion for transmitting the sample. The ASR receives the 
sample and the ASR may also receive copies of a fob 
user's biometric data along with the sample or at a differ- 
ent time (or within a different data packet) from receiving 
the sample. 

[0155] The ASR and/or fob user 102 may correlate and/or regis- 
ter the sample with fob user information to create a data 
packet for the sample and store the data packet in digital 



and/or any storage medium known in tlie art. As used 
lierein, a data pacl<et may include tlie digitized informa- 
tion relating to at least one of a biometric sample, a regis- 
tered biometric sample, a stored biometric sample, a 
proffered biometric, a proffered biometric sample, user 
information, transponder information, and/or any other 
information. The terms "data packet," "biometric sample," 
and "sample" may be used interchangeably. As used 
herein, registered samples may include samples that have 
been proffered, stored and associated with user informa- 
tion. By storing the data packet in digital format, the ASR 
may digitize any information contained in one of the bio- 
metric scans described herein. By storing the data packet 
in any storage medium, the ASR may print and/or store 
any biometric sample. Hardcopy storage may be desirable 
for back-up and archival purposes. 
[0156] The biometric sample may also be associated with user 

information to create a data packet (step 1405). The sam- 
ple may be associated with user information at any step in 
the process such as, for example, prior to submission, 
during submission and/or after submission. In one em- 
bodiment, the user may input a PIN number or zip code 
into the POS terminal, then scan the biometric to create 



the biometric sample. The local POS system may associate 
the biometric sample data with the PIN and zip code, then 
transmit the entire pacl<et of information to the ASR. In 
another embodiment, the POS may facilitate transmitting 
the sample to an ASR, and during the transmission, the 
sample may be transmitted through a third system which 
adds personal information to the sample. 
[0157] jhe information associated with the biometric sample may 
include any information such as, for example, fob user in- 
formation, fob 102 information, fob 102 identifier infor- 
mation, fob 102 vender information, fob 102 operability 
information, and/or fob 102 manufacturing information. 
Fob 102 information is not limited to transponder infor- 
mation and may include information related to any trans- 
action instrument such as smart cards, credit cards, debit 
cards, merchant-specific cards, loyalty point cards, cash 
accounts and any other transaction instruments and/or 
accounts. The fob user information may also contain in- 
formation about the user including personal information- 
-such as name, address, and contact details; financial in- 
formation — such as one or more financial accounts asso- 
ciated with the fob user; loyalty point information — such 
as one or more loyalty point accounts (e.g., airline miles. 



charge card loyalty points, frequent diner points) associ- 
ated with the fob user; and/or non-financial information- 
-such as employee information, employer information, 
medical information, family information, and/or other in- 
formation that may be used in accordance with a fob user. 

[0158] For example, fob user may have previously associated a 
credit card account, a debit card account, and a frequent 
flier account with his biometric sample which is stored at 
an ASR. Later, when fob user desires to purchase gro- 
ceries, fob user may submit his biometric sample while 
using fob 102 for the purchase at a POS. The POS may fa- 
cilitate sending the biometric sample to the ASR such that 
the ASR authorizes the biometric sample and checks a 
look-up table in the ASR database to determine if any in- 
formation is associated with the sample. If information 
(e.g., financial accounts) is associated with the sample, 
the ASR may transmit the information to the POS terminal. 
The POS terminal may then present fob user with a list of 
the three accounts associated with the biometric sample. 
Fob user and/or a merchant may then chose one of the 
accounts in order to continue and finalize the transaction. 

[0159] In another embodiment, fob user may associate each ac- 
count with a different biometric sample. For example. 



during registration, fob user may submit a sample of iiis 
right index fingerprint, and request that the system pri- 
marily associate this sample with a particular credit card 
account. Fob user may additionally submit a sample of his 
left index fingerprint and request that the system primar- 
ily associate the sample with a particular debit account. 
Additionally, fob user may submit his right thumbprint 
and request that the system primarily associate that sam- 
ple with a particular frequent flier account. By "primarily" 
associating a sample with an account, the system initially 
associates the sample with that account. For example, fob 
user submitting his right index fingerprint for a financial 
transaction may have money for the transaction taken 
from his credit card account. Fob user may additionally 
specify which accounts should be secondarily associated 
with a sample. For example, fob user may have a debit 
card account secondarily associated with his right index 
fingerprint. As a result, if fob user submits his right index 
fingerprint for a transaction, and the primary account as- 
sociated with the sample is overdrawn or unavailable, the 
secondary account may be accessed in order to further 
the transaction. 

[0160] While primary and secondary account association is de- 



scribed herein, any number of accounts may be associated 
with a sample. l\/loreover, any hierarchy or rules may be 
implemented with respect to the association. For example, 
the fob user may instruct the system to access a debit 
card account when it receives a right index fingerprint 
sample, the purchase qualifies for loyalty points with a 
certain airline and the purchase amount is less than $50. 
The fob user may additionally instruct the system to ac- 
cess a credit card account if it receives a right index fin- 
gerprint sample, the purchase does not qualify for airline 
miles and the purchase amount is greater than $50. Fur- 
ther, while fingerprint samples are discussed herein, any 
biometric sample may have one or more accounts associ- 
ated with it and may be used to facilitate a transaction us- 
ing any of the routines discussed herein. 
[0161] The ASR and/or fob user may associate a specific fob 102 
identifier with the biometric sample by any method known 
in the art for associating an identifier (e.g., through the 
use of software, hardware and/or manual entry.) The ASR 
may additionally verify the fob user and/or fob 102 by us- 
ing one or more forms of the user's secondary identifica- 
tion (step 1407). For example, the ASR may verify the fob 
user by matching the fob information to information re- 



trieved from scanning information from a fob user's 
driver's license. Tlie ASR may verify fob 102 by contacting 
the vendor of fob 102 to confirm that fob 102 was issued 
to a specific fob user. In another embodiment, the ASR 
may activate fob 102 during the registration procedure to 
confirm that the fob 102 transponder identifier and other 
information is properly associated with the fob user and 
the fob user's specific biometric samples. The ASR may 
additionally employ one or more verification methods to 
confirm that the biometric sample belongs to the user, 
such as, for example, the ASR may request from the user 
demographic information, further biometric samples and/ 
or any other information. As used herein, "confirm," "con- 
firmation" or any similar term includes verifying or sub- 
stantially verifying the accuracy, existence, non-existence, 
corroboration, and/or the like of the information, compo- 
nent, or any portion thereof. The ASR may additionally 
employ one or more additional processing methods in or- 
der to facilitate association of a biometric sample. As used 
herein, the term processing may include scanning, detect- 
ing, associating, digitizing, printing, comparing, storing, 
encrypting, decrypting, and/or verifying a biometric and/ 
or a biometric sample, or any portion thereof. 



[0162] Upon association, autlientication and/or verification of tlie 
biometric sample and fob 102, tlie system may create a 
data packet and for the sample store the data packet and 
fob 102 identifier (step 1409) in one or more databases 
on and/or in communication with system 100 via a net- 
work, server, computer, or any other means of communi- 
cating as described herein. The database(s) may be any 
type of database described herein. For example, a bio- 
metric sample stored on fob 102 may be stored in 
database 212. The database(s) may be located at or oper- 
ated by any of the entities discussed herein such as, for 
example, the ASR and/or by a third-party biometric 
database operator. 

[0163] The information stored in the database may be sorted or 
stored according to one or more characteristics associated 
with the sample in order to facilitate faster access to the 
stored sample. For example, fingerprint samples may be 
stored in a separate database than voice prints. As an- 
other example, all fingerprints with certain whirl patterns 
may be stored in a separate sub-database and/or 
database from fingerprints with arch patterns. 

[0164] The biometric samples may also be stored and/or associ- 
ated with a personal identification number (PIN) and/or 



other identifier to facilitate access to the sample. The PIN 
may be fob user selected or randomly assigned to the 
biometric sample. The PIN may consist of any characters 
such as, for example, alphanumeric characters and/or 
foreign language characters. 
[0165] The system may further protect the samples by providing 
additional security with the sample. The security may in- 
clude, for example, encryption, decryption, security keys, 
digital certificates, firewalls and/or any other security 
methods known in the art and discussed herein. One or 
more security vendors may utilize the security methods to 
store and/or access the biometric samples. The present 
invention anticipates that storage of the biometric sam- 
ples may be such that a sample is first encrypted and/or 
stored under a security procedure, such that the sample 
may only be accessed by a vendor with the proper level of 
access or security which corresponds to or provides ac- 
cess to the stored sample. The samples may be accessible 
by certain vendors such as, for example, fob 102 transac- 
tion account provider system, an issuer system, a mer- 
chant system, a fob issuer system, an employer, a finan- 
cial institution, a non-financial institution, a loyalty-point 
provider, a company, the military, the government, a 



school, a travel entity, a transportation authority, and/or a 
security company. 
[0166] The fob of the invention may include a particular security 
system wherein the security system incorporates a partic- 
ular biometric system. As shown in FIG. 15, fob 102 in- 
cludes a biometric security system 1502 configured for 
facilitating biometric security using, for example, finger- 
print samples. As used herein, fingerprint samples may 
include samples of one or more fingerprints, thumbprints, 
palmprints, footprints, and/or any portion thereof. Bio- 
metric security system 1502 may include a biometric sen- 
sor 1504 which may be configured with a sensor and/or 
other hardware and/or software for acquiring and/or pro- 
cessing the biometric data from the person such as, for 
example, optical scanning, capacitance scanning, or oth- 
erwise sensing the portion of fob user. In one embodi- 
ment, biometric sensor 1504 of the security system 1502 
may scan a finger of a fob user in order to acquire his fin- 
gerprint characteristics into fob 102. Biometric sensor 
1504 may be in communication with a sensor interface/ 
driver 1506 such that sensor interface 1506 receives the 
fingerprint information and transmits a signal to con- 
troller 208 to facilitate activating the operation of fob 



102. A power source (e.g., battery 1503) may be in com- 
munication witli biometric sensor 1504 and sensor inter- 
face 1506 to provide tlie desired power for operation of 
tlie biometric security system components. 
[0167] In one exemplary application of fob 102 incorporating 
biometric security system 1502, the user may place his 
finger on the biometric sensor to initiate the mutual au- 
thentication process between fob 102 and RFID reader 
104, and/or to provide verification of the user's identity. 
Fob 102 may digitize the fingerprint and compare it 
against a digitized fingerprint stored in a database (e.g., 
security database 212) included on fob 102. The finger- 
print information may additionally be compared with in- 
formation from one or more third-party databases com- 
municating with fob 102 through any communication 
software and/or hardware, including for example, RFID 
reader 104, a USB connection, a wireless connection, a 
computer, a network and/or any other means for commu- 
nicating. This transfer of information may include use of 
encryption, decryption, security keys, digital certificates 
and/or other security devices to confirm the security of 
the sample. Fob 102 may additionally communicate with 
third-party databases to facilitate a comparison between 



fob 102 identifier and other fob identifiers stored witli tlie 
biometric samples. As used lierein, compare, comparison 
and similar terms may include determining similarities, 
differences, existence of elements, non-existence of ele- 
ments and/or the like. 

[0168] Protocol/sequence controller 208 may facilitate the local 
comparison to authenticate the biometric and authentica- 
tion circuit 210 may validate the information. Any of the 
embodiments may alternatively or additionally include re- 
mote comparisons performed or controlled by one or 
more third-party security vendors. One or more compari- 
son techniques and/or technologies may be used for 
comparisons. For example, for fingerprint comparisons, 
protocol/sequence controller 208 may utilize an existing 
database to compare fingerprint minutia such as, for ex- 
ample, ridge endings, bifurcation, lakes or enclosures, 
short ridges, dots, spurs and crossovers, pore size and lo- 
cation, Henry System categories such as loops, whorls, 
and arches, and/or any other method known in the art for 
fingerprint comparisons. 

[0169] Fob 102 may additionally be configured with secondary 
security procedures to confirm that fake biometric sam- 
ples are not being used. For example, to detect the use of 



fake fingers, fob 102 may be further configured to mea- 
sure blood flow, to check for correctly aligned ridges at 
the edges of the fingers, and/or any other secondary pro- 
cedure to reduce biometric security fraud. Other security 
procedures for ensuring the authenticity of biometric 
samples may include monitoring pupil dilation for retinal 
and/or iris scans, pressure sensors, blinking sensors, hu- 
man motion sensors, body heat sensors and/or any other 
procedures known in the art for authenticating the au- 
thenticity of biometric samples. 
[0170] After verifying the biometric information, fob 102 and 

RFID reader 104 may begin mutual authentication, and the 
transaction may proceed accordingly. However, the inven- 
tion contemplates that the verification of biometric infor- 
mation may occur at any point in the transaction such as, 
for example, after the mutual authentication. At any point 
in the transaction, the system may additionally request 
fob user to enter a PIN and/or other identifier associated 
with the transaction account and/or biometric sample to 
provide further verification of fob user's identification. As 
part of the transaction, fob user payor may be requested 
to select from one of the financial accounts, loyalty ac- 
counts, credit accounts, debit account, and/or other ac- 



counts associated with tlie biometric sample. The user 
may be presented with a list of account options on a dis- 
play associated with RFID reader 104, fob 102, a third- 
party security device and/or any other financial or trans- 
action device association with a transaction. In another 
embodiment, a payee may select one of the accounts. For 
example, a department store payee may manually and/or 
automatically select a department store issued account, if 
available, for a transaction. 
[017^] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using facial recognition or recognition of any 
other body part or object. As discussed herein, facial 
recognition may include recognition of any facial features 
obtained through a facial scan such as, for example, the 
eyes, nose, cheeks, jaw line, forehead, chin, ear features, 
head shape, hairline, neck features, shoulder height and/ 
or any portion thereof. Biometric security system 1502 
may include a biometric sensor 1504 which may be con- 
figured with a video camera, optical scanner, and/or other 
hardware and/or software for acquiring the biometric data 
from the person such as, for example video scanning, op- 
tical scanning or otherwise sensing any portion of fob 



user. In one embodiment, biometric sensor 1504 of the 
security system 1502 may scan tlie face of a fob user in 
order to acquire liis facial characteristics into fob 102. 
Biometric sensor 1504 may be in communication with a 
sensor/interface/driver 1506 such that sensor 1504 re- 
ceives the facial information and transmits a signal to 
controller 208 to facilitate activating the operation of fob 
102. A power source (e.g., battery 1503) may be in com- 
munication with biometric sensor 1504 and sensor inter- 
face 1506 to provide the desired power for operation of 
the biometric security system components. 
[0172] In one exemplary application of fob 102 incorporating 
biometric security system 1502, system 1502 may scan 
the facial features of the fob user to initiate the mutual 
authentication process between fob 102 and RFID reader 
104, and/or to provide verification of the user's identity. 
Security system 1502 may be configured such that fob 
user may stand at least two-feet away from sensor 1504. 
Additionally, sensor 1504 may be configured to detect fa- 
cial features of a user turned at least 30 degrees toward 
the camera. 

[0173] Fob 102 may digitize the facial scan and compare it 

against a digitized facial scan stored in a database (e.g.. 



security database 212) included on fob 102. The facial 
scan information may additionally be compared with in- 
formation from one or more third-party databases com- 
municating with fob 102 through any communication 
software and/or hardware, including for example, RFID 
reader 104, a USB connection, a wireless connection, a 
computer, a network and/or any other means for commu- 
nicating. This transfer of information may include use of 
encryption, decryption, security keys, digital certificates 
and/or other security devices to confirm the security of 
the sample. Fob 102 may additionally communicate with 
third-party databases to facilitate a comparison between 
fob 102 identifier and other fob identifiers stored with the 
biometric samples. 
[0174] Protocol/sequence controller 208 may facilitate the local 
comparison to authenticate the biometric, and authentica- 
tion circuit 210 may validate the information. Any of the 
embodiments may alternatively or additionally include re- 
mote comparisons performed or controlled by one or 
more third-party security vendors. One or more compari- 
son techniques and/or technologies may be used for 
comparisons. For example, for facial recognition, proto- 
col/sequence controller 208 may utilize an existing 



database to compare nodal points such as the distance 
between the eyes, the width of the nose, the jaw line, and 
the depth of the user's eye sockets. While only some types 
of nodal points are listed, the present invention recog- 
nizes that it is known that there are over 80 different 
nodal points on a human face that may be used for com- 
parison in the present invention. Additionally, third-party 
devices such as facial recognition software and/or hard- 
ware systems may be used to facilitate facial recognition, 
such as the systems developed by Viisage, Imagis, and 
Identix which employ complex algorithms that facilitate 
both searching facial and/or ear scans and adjusting 
stored data based on eyewear, facial hair, and other 
changes in outward facial and/or ear appearance. 
[0175] Fob 102 may additionally be configured with secondary 
security procedures to confirm that fake biometric sam- 
ples are not being used. For example, to detect the use of 
fake facial features, fob 102 may be further configured to 
measure blood flow, to detect a thermal pattern associ- 
ated with facial features, and/or any other secondary pro- 
cedure to reduce biometric security fraud. Other security 
procedures for ensuring the authenticity of biometric 
samples may include monitoring pupil dilation for retinal 



and/or iris scans, pressure sensors, blinlcing sensors, hu- 
man motion sensors, body lieat sensors and/or any otiier 
procedures known in tlie art for authenticating the au- 
thenticity of biometric samples. After verifying the bio- 
metric information, fob 102 and RFID reader 104 may be- 
gin mutual authentication by any of the methods de- 
scribed herein. 

[0176] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using voice recognition. As discussed herein, 
voice recognition may include recognition of voice and/or 
speaker features such as, phonated excitation, whispered 
excitation, frication excitation, compression, vibration, 
parametric waveforms, tone, pitch, dialect, annunciation, 
and/or any portion thereof. As discussed herein, these 
voice recognition features may be collectively referred to 
as a "voice print." Biometric security system 1502 may in- 
clude a biometric sensor 1504 which may be configured 
with an audio capture device such as a microphone, tele- 
phone, cellular phone, speaker and/or other hardware 
and/or software for acquiring the biometric data from the 
person such as, for example auditory scanning, recording 
or otherwise sensing the portion of fob user. 



[0177] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the voice print of the fob user to initiate the mutual au- 
thentication process between fob 102 and RFID reader 
104, and/or to provide verification of the user's identity. 
In one embodiment, biometric sensor 1504 of the security 
system 1502 may capture a voice print, when a user re- 
cites, for example, a pass phrase or audible PIN. Biometric 
sensor 1504 may be in communication with a sensor/ 
interface/driver 1506 such that sensor 1504 receives the 
voice print and transmits a signal to controller 208 to fa- 
cilitate activating the operation of fob 102. A power 
source (e.g., battery 1503) may be in communication with 
biometric sensor 1504 and sensor interface 1506 to pro- 
vide the desired power for operation of the biometric se- 
curity system components. 

[0178] Fob 102 may digitize the voice print and compare it 

against a digitized voice print stored in a database (e.g., 
security database 212) included on fob 102. The voice 
print information may additionally be compared with in- 
formation from one or more third-party databases com- 
municating with fob 102 through any communication 
software and/or hardware, including for example, RFID 



reader 104, a USB connection, a wireless connection, a 
computer, a networl< and/or any otiier means for commu- 
nicating. Protocol/sequence controller 208 may facilitate 
the local comparison to authenticate the biometric and 
authentication circuit 210 may validate the information. 
Any of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by 
one or more third-party security vendors. 
[0179] One or more comparison techniques and/or technologies 
may be used for comparisons. For example, for voice 
recognition, protocol/sequence controller 208 may utilize 
an existing database to compare the voice print by com- 
paring voice print waveforms in the time domain, by com- 
paring energy content in the voice prints across the fre- 
quency domain, by the use of stochastic models and/or 
template models, and/or by any other voice recognition 
method known in the art. This transfer of information may 
include use of encryption, decryption, security keys, digi- 
tal certificates and/or other security devices to confirm 
the security of the sample. Fob 102 may additionally com- 
municate with third-party databases to facilitate a com- 
parison between fob 102 identifier and other fob identi- 
fiers stored with the biometric samples. Further, the 



present invention anticipates use of one or more third- 
party devices sucli as voice recognition software and/or 
hardware systems to facilitate voice print comparisons, 
such as, for example SAFLINK and Voice Security Systems. 
[0180] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 
ample, to detect the use of a recorded voice, system 1502 
may be further configured to detect audio noise associ- 
ated with an electronic device and/or any other secondary 
procedure to thwart biometric security fraud. After verify- 
ing the biometric information, fob 102 and RFID reader 
104 may begin mutual authentication by the methods de- 
scribed herein. 

[0181] In another exemplary embodiment of the present inven- 
tion, biometric security system 1502 may be configured 
for facilitating biometric security using signature recogni- 
tion. As discussed herein, signature recognition may in- 
clude recognition of the shape, speed, stroke, stylus pres- 
sure, timing information and/or other signature informa- 
tion and/or any portion thereof during the act of signing. 
As discussed herein, these signature recognition features 



may be collectively referred to as a "signature scan." Bio- 
metric security system 1502 may include a biometric sen- 
sor 1504 which may be configured with an LCD screen, 
digitizing tablet and/or other hardware and/or software 
that facilitates digitization of biometric data from the per- 
son such as, for example signature scanning, recording or 
otherwise sensing the signature of fob user. 
[0182] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the signature scan of the fob user to initiate the mutual 
authentication process between fob 102 and RFID reader 
104, and/or to provide verification of the user's identity. 
In one embodiment, biometric sensor 1504 of the security 
system 1502 may capture a signature scan, when a user 
signs, for example, his name or a specified word or 
phrase. Biometric sensor 1504 may be in communication 
with a sensor/interface/driver 1506 such that sensor 
1504 receives the signature scan and transmits a signal to 
controller 208 to facilitate activating the operation of fob 
102. A power source (e.g., battery 1503) may be in com- 
munication with biometric sensor 1504 and sensor inter- 
face 1506 to provide the desired power for operation of 
the biometric security system components. 



[0183] Fob 102 may digitize tlie signature scan and compare it 
against a digitized signature scan stored in a database 
(e.g., security database 212) included on fob 102. The 
signature scan information may additionally be compared 
with information from one or more third-party databases 
communicating with fob 102 through any communication 
software and/or hardware, including for example, RFID 
reader 104, a USB connection, a wireless connection, a 
computer, a network and/or any other means for commu- 
nicating. Protocol/sequence controller 208 may facilitate 
the local comparison to authenticate the biometric and 
authentication circuit 210 may validate the information. 
Any of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by 
one or more third-party security vendors. 

[0184] For example, for voice recognition, protocol/sequence 
controller 208 may utilize an existing database to com- 
pare the features of a signature scan by comparing 
graphs, charts, and or other data relating to shape, speed, 
stroke, stylus pressure, timing information and/or by any 
other signature recognition data. This transfer of informa- 
tion may include use of encryption, decryption, security 
keys, digital certificates and/or other security devices to 



confirm the security of tlie sample. Fob 102 may addition- 
ally communicate with third-party databases to facilitate a 
comparison between fob 102 identifier and other fob 
identifiers stored with the biometric samples. Further, the 
present invention anticipates use of one or more third- 
party devices such as signature recognition software and/ 
or hardware systems to facilitate signature scan compar- 
isons, such as, for example CyberSIGN, LCI Computer 
Group, and Xenetek. 

[0185] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 
ample, to detect the use of a false signature device, sys- 
tem 1502 may be further configured to detect a thermal 
pattern associated with a human hand and/or any other 
secondary procedure to thwart biometric security fraud. 
After verifying the biometric information, fob 102 and 
RFID reader 104 may begin mutual authentication by the 
methods described herein. 

[0186] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using vascular pattern recognition. As discussed 



herein, vascular pattern may include recognition of struc- 
tures, depths, and other biometric reference points of ar- 
terial tissues, vein tissues, capillary tissues, epithelial tis- 
sues, connective tissues, muscle tissues, nervous and/or 
other inner tissues and/or any portion thereof. As dis- 
cussed herein, these vascular pattern features may be col- 
lectively referred to as a "vascular scan." Biometric secu- 
rity system 1502 may include a biometric sensor 1504 
which may be configured with an optical scanner, thermal 
scanner and/or other hardware and/or software that facil- 
itates capture of biometric data from the person such as, 
for example scanning, detecting or otherwise sensing a 
vascular pattern of fob user. 
[0187] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the vascular scan of the fob user to initiate the mutual au- 
thentication process between fob 102 and RFID reader 
104, and/or to provide verification of the user's identity. 
In one embodiment, biometric sensor 1504 of the security 
system 1502 may capture a vascular scan, when a user 
places his hand in front of an optical scanner. Biometric 
sensor 1504 may be in communication with a sensor/ 
interface /driver 1506 such that sensor 1504 receives the 



vascular scan and transmits a signal to controller 208 to 
facilitate activating the operation of fob 102. A power 
source (e.g., battery 1503) may be in communication with 
biometric sensor 1504 and sensor interface 1506 to pro- 
vide the desired power for operation of the biometric se- 
curity system components. 

[0188] Fob 102 may digitize the vascular scan based on biomet- 
ric reference points and compare it against a digitized 
vascular scan stored in a database (e.g., security database 
212) included on fob 102. The vascular scan information 
may additionally be compared with information from one 
or more third-party databases communicating with fob 
102 through any communication software and/or hard- 
ware, including for example, RFID reader 104, a USB con- 
nection, a wireless connection, a computer, a network 
and/or any other means for communicating. Protocol/ 
sequence controller 208 may facilitate the local compari- 
son to authenticate the biometric and authentication cir- 
cuit 210 may validate the information. Any of the embodi- 
ments may alternatively or additionally include remote 
comparisons performed or controlled by one or more 
third-party security vendors. 

[0189] For example, for vascular pattern recognition, protocol/ 



sequence controller 208 may utilize an existing database 
to compare the vascular scan by comparing biometric ref- 
erence points, vascular coordinates, vascular and/or tis- 
sue lengths, widths and depths; blood pressure including 
waveforms, dicrotic notches, diastolic pressure, systolic 
pressure, anacrotic notches and pulse pressure, and/or 
any other characteristic of vascular and/or tissue patterns. 
This transfer of information may include use of encryp- 
tion, decryption, security keys, digital certificates and/or 
other security devices to confirm the security of the sam- 
ple. Fob 102 may additionally communicate with third- 
party databases to facilitate a comparison between fob 
102 identifier and other fob identifiers stored with the 
biometric samples. Further, the present invention antici- 
pates use of one or more third-party devices such as vas- 
cular pattern recognition software and/or hardware sys- 
tems to facilitate vascular scan comparisons, such as, for 
example VEID International, Identica and ABT Advanced 
Biometric Technologies. 
[0190] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 



ample, to detect the use of a false vascular patterns, sys- 
tem 1502 may be further configured to detect a thermal 
pattern associated with vascular patterns and/or any other 
secondary procedure to thwart biometric security fraud. 
After verifying the biometric information, fob 102 and 
RFID reader 104 may begin mutual authentication by the 
methods described herein. 

[0191] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using DNA biometrics. As discussed herein, DNA 
biometrics may include recognition of structures, gene 
sequences, and other genetic characteristics of skin tis- 
sue, hair tissue, and/or any other human tissue and/or 
any portion thereof containing genetic information. As 
discussed herein, these genetic features may be collec- 
tively referred to as a "DNA scan." Biometric security sys- 
tem 1502 may include a biometric sensor 1504 which may 
be configured with an infrared optical sensor, a chemical 
sensor and/or other hardware and/or software that facili- 
tates capture of biometric data from the person such as, 
for example scanning, detecting or otherwise sensing a 
DNA scan of fob user. 

[0192] In one exemplary application of fob 102 incorporating 



biometric security system 1502, system 1502 may capture 
the DNA scan of the fob user to initiate the mutual au- 
thentication process between fob 102 and RFID reader 
104, and/or to provide verification of the user's identity. 
In one embodiment, biometric sensor 1504 of the security 
system 1502 may capture a DNA scan, when a user sub- 
mits genetic material to sensor 1504. Biometric sensor 
1504 may be in communication with a sensor/inter- 
face/driver 1506 such that sensor 1504 receives the DNA 
scan and transmits a signal to controller 208 to facilitate 
activating the operation of fob 102. A power source (e.g., 
battery 1503) may be in communication with biometric 
sensor 1504 and sensor interface 1506 to provide the de- 
sired power for operation of the biometric security system 
components. 

[0193] Fob 102 may digitize the DNA scan based on genetic in- 
formation reference points and compare it against a digi- 
tized DNA scan stored in a database (e.g., security 
database 212) included on fob 102. The DNA scan infor- 
mation may additionally be compared with information 
from one or more third-party databases communicating 
with fob 102 through any communication software and/or 
hardware, including for example, RFID reader 104, a USB 



connection, a wireless connection, a computer, a networlc 
and/or any otiier means for communicating. Protocol/ 
sequence controller 208 may facilitate the local compari- 
son to authenticate the biometric and authentication cir- 
cuit 210 may validate the information. Any of the embodi- 
ments may alternatively or additionally include remote 
comparisons performed or controlled by one or more 
third-party security vendors. 
[0194] For example, for DNA recognition, protocol/sequence 
controller 208 may utilize an existing database to com- 
pare the DNA scan by comparing nucleotides, code se- 
quences, regulatory regions, initiation and stop codons, 
exon/intron borders, and/or any other characteristics of 
DNA. This transfer of information may include use of en- 
cryption, decryption, security keys, digital certificates 
and/or other security devices to confirm the security of 
the sample. Fob 102 may additionally communicate with 
third-party databases to facilitate a comparison between 
fob 102 identifier and other fob identifiers stored with the 
biometric samples. Further, the present invention antici- 
pates use of one or more third-party devices such as DNA 
recognition software and/or hardware systems to facilitate 
DNA scan comparisons, such as, for example Applied DNA 



Sciences. 

[0195] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fal<e biometric samples are not being used. For ex- 
ample, to detect the use false DNA, system 1502 may be 
further configured to take a DNA sample directly off a 
user and/or any other secondary procedure to thwart bio- 
metric security fraud. After verifying the biometric infor- 
mation, fob 102 and RFID reader 104 may begin mutual 
authentication by the methods described herein. 

[0196] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using hand geometry biometrics. As discussed 
herein, hand geometry biometrics may include recognition 
of hand geometry parameters, such as, for example, hand 
shape, finger length, finger thickness, finger curvature 
and/or any portion thereof. As discussed herein, these 
hand geometry features may be collectively referred to as 
a "hand geometry scan." Biometric security system 1502 
may include a biometric sensor 1504 which may be con- 
figured with an infrared optical sensor, a three-di- 
mensional imaging system and/or other hardware and/or 



software that facilitates capture of biometric data from the 
person such as, for example scanning, detecting or other- 
wise sensing a hand geometry scan of fob user. 

[0197] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the hand geometry scan of the fob user to initiate the mu- 
tual authentication process between fob 102 and RFID 
reader 104, and/or to provide verification of the user's 
identity. In one embodiment, biometric sensor 1504 of 
the security system 1502 may capture a hand geometry 
scan, when a user places his hand in front of an optical 
scanner. Biometric sensor 1504 may be in communication 
with a sensor/interface/driver 1506 such that sensor 
1504 receives the hand geometry scan and transmits a 
signal to controller 208 to facilitate activating the opera- 
tion of fob 102. A power source (e.g., battery 1503) may 
be in communication with biometric sensor 1504 and 
sensor interface 1506 to provide the desired power for 
operation of the biometric security system components. 

[0198] Fob 102 may digitize the hand geometry scan based on 
hand geometry parameters and compare it against a digi- 
tized hand geometry scan stored in a database (e.g., se- 
curity database 212) included on fob 102. The hand ge- 



ometry scan information may additionally be compared 
with information from one or more third-party databases 
communicating with fob 102 through any communication 
software and/or hardware, including for example, RFID 
reader 104, a USB connection, a wireless connection, a 
computer, a network and/or any other means for commu- 
nicating. Protocol/sequence controller 208 may facilitate 
the local comparison to authenticate the biometric and 
authentication circuit 210 may validate the information. 
Any of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by 
one or more third-party security vendors. 
[0199] For example, for hand geometry recognition, protocol/ 
sequence controller 208 may utilize an existing database 
to compare hand shape, finger length, finger thickness, 
finger curvature and/or any other of the 90 different hand 
geometry parameters known in the art. This transfer of 
information may include use of encryption, decryption, 
security keys, digital certificates and/or other security de- 
vices to confirm the security of the sample. Fob 102 may 
additionally communicate with third-party databases to 
facilitate a comparison between fob 102 identifier and 
other fob identifiers stored with the biometric samples. 



Further, the present invention anticipates use of one or 
more third-party devices such as hand geometry recogni- 
tion software and/or hardware systems to facilitate hand 
geometry scan comparisons, such as, for example IR 
Recognition Services and Human Recognition Services. 
[0200] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 
ample, to detect the use of false hands, system 1502 may 
be further configured to measure blood flow, to detect 
body heat and/or any other secondary procedure to 
thwart biometric security fraud. After verifying the bio- 
metric information, fob 102 and RFID reader 104 may be- 
gin mutual authentication by the methods described 
herein. 

[0201] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using auditory emissions biometrics. As dis- 
cussed herein, auditory emissions biometrics may include 
emissions that an ear generates when stimulated by 
sound, such as vibrations and reverberated sound waves 
and/or any portion thereof. As discussed herein, these 



auditory emissions features may be collectively referred to 
as an "auditory emissions scan." Biometric security system 
1502 may include a biometric sensor 1504 which may be 
configured with an infrared optical sensor, an auditory 
sensor, an auditory generator and/or other hardware and/ 
or software that facilitates the capture of biometric data 
from the person such as, for example sound generating, 
scanning, detecting or otherwise sensing an auditory 
emissions scan of fob user. 
[0202] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the auditory emissions scan of the fob user to initiate the 
mutual authentication process between fob 102 and RFID 
reader 104, and/or to provide verification of the user's 
identity. In one embodiment, biometric sensor 1504 of 
the security system 1502 may capture an auditory emis- 
sions scan, when a user hears an auditory stimulant and 
the user's auditory emissions are detected by biometric 
sensor 1504. Biometric sensor 1504 may be in communi- 
cation with a sensor/interface/driver 1506 such that sen- 
sor 1504 receives the auditory emissions scan and trans- 
mits a signal to controller 208 to facilitate activating the 
operation of fob 102. A power source (e.g., battery 1503) 



may be in communication with biometric sensor 1504 and 
sensor interface 1506 to provide tlie desired power for 
operation of tlie biometric security system components. 

[0203] Fob 102 may digitize tlie auditory emissions scan based 
on emissions waveforms and compare it against a digi- 
tized auditory emissions scan stored in a database (e.g., 
security database 212) included on fob 102. The auditory 
emissions scan information may additionally be compared 
with information from one or more third-party databases 
communicating with fob 102 through any communication 
software and/or hardware, including for example, RFID 
reader 104, a USB connection, a wireless connection, a 
computer, a network and/or any other means for commu- 
nicating. Protocol/sequence controller 208 may facilitate 
the local comparison to authenticate the biometric and 
authentication circuit 210 may validate the information. 
Any of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by 
one or more third-party security vendors. 

[0204] For example, for auditory emissions recognition, proto- 
col/sequence controller 208 may utilize an existing 
database to compare emissions difference in frequency, 
wavelength, and/or other characteristics between the 



transmitted and reverberated sound waves. This transfer 
of information may include use of encryption, decryption, 
security keys, digital certificates and/or other security de- 
vices to confirm the security of the sample. Fob 102 may 
additionally communicate with third-party databases to 
facilitate a comparison between fob 102 identifier and 
other fob identifiers stored with the biometric samples. 
Further, the present invention anticipates use of one or 
more third-party devices such as auditory emissions 
recognition software and/or hardware systems to facilitate 
auditory emissions scan comparisons, such as, for exam- 
ple those developed by the University of Southampton. 
[0205] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 
ample, to detect the use of false auditory emissions scans, 
system 1502 may be further configured to detect elec- 
tronic noise associated with a device producing electronic 
auditory emissions and/or any other secondary procedure 
to thwart biometric security fraud. After verifying the bio- 
metric information, fob 102 and RFID reader 104 may be- 
gin mutual authentication by the methods described 



herein. 

[0206] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using olfactory biometrics. As discussed herein, 
olfactory biometrics may include odorants that a body 
generates when odor evaporates from and/or any portion 
thereof. As discussed herein, these odorants may be col- 
lectively referred to as a "smellprint." Biometric security 
system 1502 may include a biometric sensor 1504 which 
may be configured with an electronic sensor, a chemical 
sensor, and/or an electronic or chemical sensor config- 
ured as an array of chemical sensors, wherein each chem- 
ical sensor may detect a specific odorant, or smell. In an- 
other embodiment, biometric sensor 1504 may be config- 
ured as a gas chromatograph, spectrometer, conductivity 
sensor, piezoelectric sensor and/or other hardware and/ 
or software that facilitates the capture of biometric data 
from the person such as, for example, scanning, detecting 
or otherwise sensing a smellprint of fob user. 

[0207] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the smellprint of the fob user to initiate the mutual au- 
thentication process between fob 102 and RFID reader 



104, and/or to provide verification of tlie user's identity. 
In one embodiment, biometric sensor 1504 of the security 
system 1502 may capture a smellprint, when a user 
stands within at least two feet of sensor 1504. Biometric 
sensor 1504 may be in communication with a sensor/ 
interface/driver 1506 such that sensor 1504 receives the 
smellprint and transmits a signal to controller 208 to fa- 
cilitate activating the operation of fob 102. A power 
source (e.g., battery 1503) may be in communication with 
biometric sensor 1504 and sensor interface 1506 to pro- 
vide the desired power for operation of the biometric se- 
curity system components. 
[0208] Fob 102 may digitize the smellprint and compare it 

against a digitized smellprint stored in a database (e.g., 
security database 212) included on fob 102. The smell- 
print information may additionally be compared with in- 
formation from one or more third-party databases com- 
municating with fob 102 through any communication 
software and/or hardware, including for example, RFID 
reader 104, a USB connection, a wireless connection, a 
computer, a network and/or any other means for commu- 
nicating. Protocol/sequence controller 208 may facilitate 
the local comparison to authenticate the biometric and 



authentication circuit 210 may validate the information. 
Any of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by 
one or more third-party security vendors. 

[0209] For example, for smellprints, protocol/sequence con- 
troller 208 may utilize an existing database to compare 
the difference in molecular structures, chemical com- 
pounds, temperature, mass differences, pressure, force, 
and odorants by using statistical, ANN and neuromorphic 
techniques. This transfer of information may include use 
of encryption, decryption, security keys, digital certificates 
and/or other security devices to confirm the security of 
the sample. Fob 102 may additionally communicate with 
third-party databases to facilitate a comparison between 
fob 102 identifier and other fob identifiers stored with the 
biometric samples. Further, the present invention antici- 
pates use of one or more third-party devices such as 
smellprint recognition software and/or hardware systems 
to facilitate smellprint comparisons, such as, for example 
those developed by Company Mastiff Electronic Systems. 

[0210] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 



that fake biometric samples are not being used. For ex- 
ample, to detect the use of a false odorant, system 1502 
may be further configured to detect man-made smells, 
abnormal odorants, body heat and/or any other secondary 
procedure to thwart biometric security fraud. After verify- 
ing the biometric information, fob 102 and RFID reader 
104 may begin mutual authentication by the methods de- 
scribed herein. 
^] In another exemplary embodiment, biometric security 
system 1502 may be configured for facilitating biometric 
security using keystroke/typing recognition biometrics. As 
discussed herein, keystroke/typing recognition biometrics 
may include recognition of the duration of keystrokes, la- 
tencies between keystrokes, inter-keystroke times, typing 
error frequency, force keystrokes and/or any portion 
thereof. As discussed herein, these features may be col- 
lectively referred to as a "keystroke scan." Biometric secu- 
rity system 1502 may include a biometric sensor 1504 
which may be configured with an electronic sensor, an 
optical sensor, a keyboard, and/or other hardware and/or 
software that facilitates the capture of biometric data from 
the person such as, for example, scanning, detecting or 
otherwise sensing a keystroke scan of fob user. 



[0212] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the keystroke scan of the fob user to initiate the mutual 
authentication process between fob 102 and RFID reader 
104, and/or to provide verification of the user's identity. 
In one embodiment, biometric sensor 1504 of the security 
system 1502 may capture a keystroke scan, when a user 
types, for example, a PIN or pass phrase into a keyboard 
configured with sensor 1504. Biometric sensor 1504 may 
be in communication with a sensor/interface/driver 1506 
such that sensor 1504 receives the keystroke scan and 
transmits a signal to controller 208 to facilitate activating 
the operation of fob 102. A power source (e.g., battery 
1503) may be in communication with biometric sensor 
1504 and sensor interface 1506 to provide the desired 
power for operation of the biometric security system 
components. 

[0213] Fob 102 may digitize the keystroke scan based on 

keystroke characteristics and compare the scan against a 
digitized keystroke scan stored in a database (e.g., secu- 
rity database 212) included on fob 102. The keystroke 
scan information may additionally be compared with in- 
formation from one or more third-party databases com- 



municating with fob 102 through any communication 
software and/or hardware, including for example, RFID 
reader 104, a USB connection, a wireless connection, a 
computer, a network and/or any other means for commu- 
nicating. Protocol/sequence controller 208 may facilitate 
the local comparison to authenticate the biometric and 
authentication circuit 210 may validate the information. 
Any of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by 
one or more third-party security vendors. 
[0214] For example, for keystroke scans, protocol/sequence con- 
troller 208 may utilize an existing database to compare 
the behavioral, temporal and physical characteristics as- 
sociated with keystrokes. This transfer of information may 
include use of encryption, decryption, security keys, digi- 
tal certificates and/or other security devices to confirm 
the security of the sample. Fob 102 may additionally com- 
municate with third-party databases to facilitate a com- 
parison between fob 102 identifier and other fob identi- 
fiers stored with the biometric samples. Further, the 
present invention anticipates use of one or more third- 
party devices such as keystroke scan recognition software 
and /or hardware systems to facilitate keystroke scan 



comparisons, such as, for example those developed by 
BioPassword® by BioNet Systems, LLC. 

[0215] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 
ample, to detect the use of a false keystroke, system 1502 
may be further configured to detect body heat and/or any 
other secondary procedure to thwart biometric security 
fraud. After verifying the biometric information, fob 102 
and RFID reader 104 may begin mutual authentication by 
the methods described herein. 

[0216] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using iris scan biometrics. As discussed herein, 
iris scan biometrics may include recognition of character- 
istics of the colored tissues surrounding the pupil, such as 
the rings, furrows and freckles and/or any portion 
thereof. As discussed herein, these characteristics may be 
collectively referred to as an "iris scan." Biometric security 
system 1502 may include a biometric sensor 1504 which 
may be configured with a video camera, an optical scan- 
ner, a digital camera, a charge coupled device and/or 



other hardware and /or software that facilitates the cap- 
ture of biometric data from the person such as, for exam- 
ple, scanning, detecting or otherwise sensing an iris scan 
of fob user. 

[0217] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the iris scan of the fob user to initiate the mutual authen- 
tication process between fob 102 and RFID reader 104, 
and/or to provide verification of the user's identity. In one 
embodiment, biometric sensor 1504 of the security sys- 
tem 1502 may capture an iris scan, when a user uses sen- 
sor 1504 to scan his iris while he is up to five feet away 
from sensor 1504. Sensor 1504 may scan the user's iris 
through contacts, sunglasses, and/or any other type of 
eye glasses. Biometric sensor 1504 may be in communi- 
cation with a sensor interface /driver 1506 such that sen- 
sor 1504 receives the iris scan and transmits a signal to 
controller 208 to facilitate activating the operation of fob 
102. A power source (e.g., battery 1503) may be in com- 
munication with biometric sensor 1504 and sensor inter- 
face 1506 to provide the desired power for operation of 
the biometric security system components. 

[0218] Fob 102 may digitize the iris scan based on iris character- 



istics and compare the scan against a digitized iris scan 
stored in a database (e.g., security database 212) included 
on fob 102. The iris scan information may additionally be 
compared with information from one or more third-party 
databases communicating with fob 102 through any com- 
munication software and/or hardware, including for ex- 
ample, RFID reader 104, a USB connection, a wireless con- 
nection, a computer, a network and/or any other means 
for communicating. Protocol/sequence controller 208 may 
facilitate the local comparison to authenticate the biomet- 
ric and authentication circuit 210 may validate the infor- 
mation. Any of the embodiments may alternatively or ad- 
ditionally include remote comparisons performed or con- 
trolled by one or more third-party security vendors. 
[0219] For example, for iris scans, protocol/sequence controller 
208 may utilize an existing database to compare the sur- 
face patterns of the iris by localizing the boundaries and 
the eyelid contours of the iris and creating a phase code 
for the texture sequence in the iris. This transfer of infor- 
mation may include use of encryption, decryption, security 
keys, digital certificates and/or other security devices to 
confirm the security of the sample. Fob 102 may addition- 
ally communicate with third-party databases to facilitate a 



comparison between fob 102 identifier and otiier fob 
identifiers stored with the biometric samples. Further, the 
present invention anticipates use of one or more third- 
party devices such as iris scan recognition software and/ 
or hardware systems to facilitate iris scan comparisons, 
such as, for example those developed by Iridian, LG Elec- 
tronics and BioCom. 

[0220] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 
ample, to detect the use of a false iris, system 1502 may 
be further configured to vary the light shone into the eye 
to watch for pupil dilation, to detect body heat and/or any 
other secondary procedure to thwart biometric security 
fraud. After verifying the biometric information, fob 102 
and RFID reader 104 may begin mutual authentication by 
the methods described herein. 

[0221] In another exemplary embodiment, biometric security 

system 1502 may be configured for facilitating biometric 
security using retinal scanning biometrics. As discussed 
herein, retinal scanning biometrics may include recogni- 
tion of characteristics of the reflected retinal pattern of 



the eye, such as the location, structure, size, and shape of 
blood vessels and/or any portion thereof. As discussed 
herein, these characteristics may be collectively referred 
to as a "retinal scan." Biometric security system 1502 may 
include a biometric sensor 1504 which may be configured 
with low-intensity light source, such as an infrared 
source, an optical coupler and/or other hardware and/or 
software that facilitates the capture of biometric data from 
the person such as, for example, scanning, detecting or 
otherwise sensing a retinal scan of fob user. 
[0222] In one exemplary application of fob 102 incorporating 

biometric security system 1502, system 1502 may capture 
the iris scan of the fob user to initiate the mutual authen- 
tication process between fob 102 and RFID reader 104, 
and/or to provide verification of the user's identity. In one 
embodiment, biometric sensor 1504 of the security sys- 
tem 1502 may capture a retinal scan, when a sensor 1504 
shines a light source into the user's retina and detects the 
reflected retina pattern. Sensor 1504 may detect a user's 
retinal pattern when the user is up to five feet away from 
sensor 1504. Biometric sensor 1504 may be in communi- 
cation with a sensor interface /driver 1506 such that sen- 
sor 1504 receives the retinal scan and transmits a signal 



to controller 208 to facilitate activating the operation of 
fob 102. A power source (e.g., battery 1503) may be in 
communication with biometric sensor 1504 and sensor 
interface 1506 to provide the desired power for operation 
of the biometric security system components. 
[0223] Fob 102 may digitize the retinal scan based on retinal 
characteristics and compare the scan against a digitized 
iris scan stored in a database (e.g., security database 212) 
included on fob 102. The retinal scan information may 
additionally be compared with information from one or 
more third-party databases communicating with fob 102 
through any communication software and/or hardware, 
including for example, RFID reader 104, a USB connection, 
a wireless connection, a computer, a network and/or any 
other means for communicating. Protocol/sequence con- 
troller 208 may facilitate the local comparison to authen- 
ticate the biometric and authentication circuit 210 may 
validate the information. Any of the embodiments may al- 
ternatively or additionally include remote comparisons 
performed or controlled by one or more third-party secu- 
rity vendors. 

[0224] For example, for retinal scans, protocol/sequence con- 
troller 208 may utilize an existing database to compare 



the blood vessel patterns of the retina by comparing 
stored and detected retinal patterns. This transfer of in- 
formation may include use of encryption, decryption, se- 
curity keys, digital certificates and/or other security de- 
vices to confirm the security of the sample. Fob 102 may 
additionally communicate with third-party databases to 
facilitate a comparison between fob 102 identifier and 
other fob identifiers stored with the biometric samples. 
Further, the present invention anticipates use of one or 
more third-party devices such as retinal scan recognition 
software and/or hardware systems to facilitate keystroke 
scan comparisons, such as, for example those developed 
by EyeKey and Retinal Technologies. 
[0225] Fob 102 and/or any other third-party security vendor sys- 
tem used in connection with fob 102 may additionally be 
configured with secondary security procedures to confirm 
that fake biometric samples are not being used. For ex- 
ample, to detect the use of a false retina, system 1502 
may be further configured to vary the light shone into the 
eye to watch for pupil dilation, to detect body heat and/or 
any other secondary procedure to thwart biometric secu- 
rity fraud. After verifying the biometric information, fob 
102 and RFID reader 104 may begin mutual authentication 



by the methods described herein. 
[0226] In an additional or alternate embodiment, RFID reader 104 
may include one or more security system, wherein the se- 
curity system incorporates one or more biometric system. 
As shown in FIG. 16, RFID reader 104 includes a biometric 
security system 1602 configured for facilitating biometric 
security using a biometric sample. Biometric security sys- 
tem 1602 may include a biometric sensor 1604 which may 
be configured with a sensor, video camera, digital camera, 
optical scanner, light source and/or other hardware and/ 
or software for acquiring biometric data form the person 
such as, for example, optical scanning, chemical sensing, 
or otherwise detecting the portion of fob user. Biometric 
sensor 1604 may be in communication with a sensor in- 
terface/driver 1606 such that sensor interface 1606 re- 
ceives biometric information and transmits a signal to 
controller 208 to facilitate activating the operation of fob 
102. 

[0227] In one exemplary application of RFID reader 104 including 
biometric security system 1602, the user may submit a 
biometric sample to the biometric sensor to initiate the 
mutual authentication process between fob 102 and RFID 
reader 104, and/or to provide verification of the user's 



identity. RFID reader 104 may digitize tlie sample and 
compare it against a digitized biometric sample stored in 
a database (e.g., database 310) included on RFID reader 
104. The biometric sample information may additionally 
be compared with information from one or more third- 
party databases communicating with fob 102 through any 
communication software and/or hardware, including for 
example, fob 102, a USB connection, a wireless connec- 
tion, a computer, a network and/or any other means for 
communicating. The transfer of information may include 
use of encryption decryption, security keys, digital certifi- 
cates and/or other security devices to confirm the security 
of the sample. RFID reader 104 may additionally commu- 
nicate with third-party databases to facilitate a compari- 
son between fob 102 identifier and other fob identifiers 
stored with the biometric samples. 
[0228] Protocol/sequence controller 314 may facilitate the local 
comparison to authenticate the biometric sample and au- 
thentication circuit 308 may validate the information. Any 
of the embodiments may alternatively or additionally in- 
clude remote comparisons performed or controlled by 
third-party security vendors in anyway known in the art 
for comparing biometric data. 



[0229] RpiD reader 104 may also be configured with secondary 
security procedures biometric to confirm that fal<e bio- 
metric samples are not being used. For example, RFID 
reader 104 may be further configured to measure blood 
flow, body heat and/or any other secondary procedure to 
reduce biometric security fraud. Other security procedures 
for ensuring the authenticity of biometric samples may in- 
clude monitoring pupil dilation for retinal and/or iris 
scans, pressure sensors, blinking sensors, human motion 
sensors, and/or any other procedures known in the art for 
authenticating the authenticity of biometric samples. After 
verifying the biometric information, fob 102 and RFID 
reader 104 may begin mutual authentication, and the 
transaction may proceed accordingly. 

[0230] While the biometric safeguard mechanisms describe fob 
102 and/or RFID reader 104 configured with a biometric 
safeguard mechanism, any part of system 100 may be 
equipped with a biometric safeguard system. For example, 
the invention contemplates receiving a biometric sample 
only at the reader, only at the fob, at both the fob and the 
reader, or at any other combination of location or device. 
As such, any scanner or database discussed herein may be 
located within or associated with another device. For ex- 



ample, the fob may scan a user biometric, but the 
database used for comparison may be located within the 
reader or merchant server. In other embodiments, the 
biometric security device may be located away from the 
point of sale device and/or provide other functions. For 
example, the biometric security device may be located 
near the item to be purchased or located in any other lo- 
cation within or outside of the merchant. In one embodi- 
ment, the biometric security device may be located out- 
side of a jewelry display to allow a user to not only start 
the authentication process before check-out, but also to 
allow access to the product within the display case. In this 
regard, the biometric security device may communicate 
the information to the point of sale device so the POS may 
verify that the person that entered the jewelry box is the 
same person that is now buying the jewelry. In another 
embodiment, any portion of system 100 may be config- 
ured with a biometric security device. The biometric secu- 
rity device may be attached and/or free-standing. Biomet- 
ric security devices may be configured for local and/or 
third-party operation. For example, the present invention 
contemplates the use of third-party fingerprint scanning 
and security devices such as those made by Interlink Elec- 



ironies, Keytronic, Identix Biotouch, BIOmetricID, onClick, 
and/or other third-party vendors. 

[0231] In yet another embodiment, the database used for com- 
parison may contain terrorist and/or criminal information. 
As used herein, terrorists and/or criminals may include 
terrorists, felons, criminals, convicts, indicted persons, in- 
surgents, revolutionaries and/or other offenders. The in- 
formation may include biometric information, personal in- 
formation as described herein, arrest records, aliases 
used, country of residence, affiliations with gangs and 
terrorist groups, and/or any other terrorist and/or crimi- 
nal information. 

[0232] As an example of a secondary security procedure in ac- 
cordance with the present invention, the biometric sensor 
1504, 1604 may be configured to allow a finite number of 
scans. For example, biometric sensor 1504, 1604 may be 
configured to only accept data from a single scan. As a 
result, biometric sensor 1504, 1604 may turn off or deac- 
tivate fob 102 and/or RFID reader 104 if more than one 
scan is needed to obtain a biometric sample. Biometric 
sensor 1504, 1604 may also be configured to accept a 
preset limit of scans. For example, biometric sensor 1504, 
1604 may receive three invalid biometric samples before 



it turns off and/or deactivates fob 102 and/or RFID reader 
104. 

[0233] The sensor or any otiier part of system 100 may also acti- 
vate upon sensing a particular type or group of biometric 
samples. The activation may include sending a signal, 
blinking, audible sound, visual display and/or the like. For 
example, if the sensor detects information from a gold 
card member, the system may display a special offer on 
the POS terminal. If the sensor detects a repeat customer, 
the sensor may signal or notify a manager to approach the 
customer and thank them for their repeat business. In an- 
other embodiment, the system may send a signal to a pri- 
mary account holder or any other person or device to no- 
tify them that the fob is being used or that a condition or 
rule is being violated (e.g., charge above $1000). 

[0234] Any of the biometric security systems described herein 
may additionally be configured with a fraud protection 
log. That is, a biometric security system, such as biomet- 
ric security system 1502, 1602 may be configured to log 
all biometric samples submitted on fob 102 and/or RFID 
reader 104 and store the log information on databases on 
and/or communicating with system 1502, 1602. If a new 
and/or different biometric sample is submitted that dif- 



fers from the log data, biometric security system 1502, 
1602 may employ a security procedure such as deactiva- 
tion, warning authorities, requesting a secondary scan, 
and/or any other security procedure. 
[0235] Biometric security system 1502, 1602 and/or the biomet- 
ric security system configured with system 100 may also 
be configured to obtain a plurality of biometric samples 
for verification and/or other security purposes. For exam- 
ple, after biometric security system 1502, receives a first 
biometric sample (e.g., scans one finger,) it may be con- 
figured to receive a second biometric sample (e.g., scans a 
second finger). The first and second biometric samples 
may be compared with stored biometric samples by any of 
the methods disclosed herein. The second biometric sam- 
ple may be the only sample compared with stored bio- 
metric samples if the first sample is unreadable or inade- 
quate. 

[0236] In yet another exemplary embodiment of the present in- 
vention, fob 102 may be equipped with a biometric safe- 
guard mechanism. For example, in one exemplary appli- 
cation of fob 102, fob 102 may use biometric security 
system 1502 to authorize a transaction that violates an 
established rule, such as, for example, a purchase ex- 



ceeding an established per purchase spending limit, a 
purchase exceeding a preset number of transactions, any 
portion of a purchase and/or transaction involving non- 
monetary funds (e.g., paying a portion of the transaction 
with loyalty points, coupons, airline miles, etc.) and/or 
any other purchase and/or transaction exceeding a preset 
or established limit. Fob user, a third-party issuer system 
a third-party financial system, a company and/or any 
other entity or system may establish the preset limits. The 
limits may be used to prevent fraud, theft, overdrafts, 
and/or other non-desirable situations associated with fi- 
nancial and non-financial accounts. For example, if fob 
102 is stolen and the thief tries to make a large purchase 
with the card, the biometric safeguard mechanism may 
prevent the purchase until fob user's identity is verified by 
biometric means. 
[0237] For example, fob 102 may activate biometric security sys- 
tem 1502 to notify a user who is attempting to make a 
large purchase that the user must provide a biometric 
sample to verify the user's identity. By notifying, fob 102 
may be configured to provide an audible signal, visual 
signal, optical signal, mechanical signal, vibration, blink- 
ing, signaling and beeping, and/or provide any other no- 



tification to a user. Accordingly, fob user may provide 
sucli verification by submitting a biometric sample, for 
example placing his finger over biometric sensor 1504 
and/or any other biometric security devices used in asso- 
ciation with fob 102. Biometric sensor 1504 may then 
digitize the biometric sample (e.g., fingerprint) and use 
the digitized sample for verification by any of the methods 
described herein. Once fob user's identity and/or fob 102 
transponder identifier are verified, fob 102 may provide a 
transaction authorized signal to RF transponder 202 
(and/or to transponder 220) for forwarding to RFID reader 
104. RFID reader 104 may then provide the transaction 
authorized signal to POS device 110 in similar manner as 
is done with conventional PIN driven systems and POS de- 
vice 110 may process the transaction under the mer- 
chant's business as usual standard. If fob 102 has been 
stolen, then fob user's identity may not be verified and the 
transaction may be cancelled. Additionally, one or more 
further security procedures may be triggered, such as, for 
example, fob 102 may deactivate, fob 102 may send a 
notification to a security vendor, fob 102 may be confis- 
cated by the merchant and/or any other security proce- 
dures may be used. 



[0238] In another exemplary embodiment, RFID reader 104 may 
be equipped witli a biometric safeguard meclianism. For 
example, in one exemplary application of RFID reader 
104, RFID reader 104 may use biometric security system 
1602 to authorize a transaction that violates an estab- 
lished rule, such as, for example, a purchase exceeding an 
established per purchase spending limit, a purchase ex- 
ceeding a preset number of transactions and/or any other 
purchase exceeding a preset or established limit. Fob 
user, a third-party issuer system a third-party financial 
system, a company and/or any other entity or system may 
establish the preset limits. The limits may be used to pre- 
vent fraud, theft, overdrafts, and/or other non-desirable 
situations associated with financial and non-financial ac- 
counts. For example, if fob 102 is stolen and the thief 
tries to make a large purchase with the card, the biometric 
safeguard mechanism may prevent the purchase until fob 
user's identity is verified by biometric means. 

[0239] In one example, where fob user is using a company-is- 
sued fob 102, fob 102 may the have a pre-set limit of 
transactions that may be completed before biometric veri- 
fication is required. If the user exceeds the transaction 
limit, RFID reader 104 may be configured to scan a bio- 



metric sample in order to verify the user's identity. Ac- 
cordingly, the user may provide such verification by sub- 
mitting a biometric sample, for example submitting a reti- 
nal scan to biometric sensor 1604. RFID reader 104 may 
then digitize the biometric sample (e.g., retinal pattern) 
and use the digitized sample for verification by any of the 
methods described herein. Once fob user's identity and/or 
fob 102 transponder identifier are verified, RFID reader 
104 may receive a transaction authorized signal from a 
security vendor authorized to give such a signal. RFID 
reader 104 may then provide the transaction authorized 
signal to POS device 110 in similar manner as is done with 
convention PIN driven systems and POS device 110 may 
process the transaction under the merchant's business as 
usual standard. 
[0240] While the biometric safeguard mechanisms described 

herein use fingerprint scanning and retinal scanning for 
biometric sample verification for exemplification, any bio- 
metric sample may be submitted for verification, autho- 
rization and/or any other safeguard purpose. For example 
the present invention contemplates the use of voice 
recognition, facial and/or ear recognition, signature 
recognition, vascular patterns, DNA sampling, hand ge- 



ometry, auditory emissions recognition, olfactory recogni- 
tion, lceystrol<e/typing recognition, iris scans, and/or any 
other biometric known in tlie art, 

[0241] jhe preceding detailed description of exemplary embodi- 
ments of the invention makes reference to the accompa- 
nying drawings, which show the exemplary embodiment 
by way of illustration. While these exemplary embodi- 
ments are described in sufficient detail to enable those 
skilled in the art to practice the invention, it should be 
understood that other embodiments may be realized and 
that logical and mechanical changes may be made without 
departing from the spirit and scope of the invention. For 
example, the steps recited in any of the method or pro- 
cess claims may be executed in any order and are not lim- 
ited to the order presented. Further, the present invention 
may be practiced using one or more servers, as necessary. 
Thus, the preceding detailed description is presented for 
purposes of illustration only and not of limitation, and the 
scope of the invention is defined by the preceding de- 
scription, and with respect to the attached claims. 

[0242] Benefits, other advantages, and solutions to problems 
have been described above with regard to specific em- 
bodiments. However, the benefits, advantages, solutions 



to problems, and any element(s) that may cause any ben- 
efit, advantage, or solution to occur or become more pro- 
nounced are not to be construed as critical, required, or 
essential features or elements of any or all the claims. As 
used herein, the terms "comprises," "comprising," or any 
other variations thereof, are intended to cover a non- 
exclusive inclusion, such that a process, method, article, 
or apparatus that comprises a list of elements does not 
include only those elements but may include other ele- 
ments not expressly listed or inherent to such process, 
method, article, or apparatus. Further, no element de- 
scribed herein is required for the practice of the invention 
unless expressly described as "essential" or "critical." 



